95-702 Transactions 1 95-702 Distributed Systems Lecture 15: Transactions and Concurrency Control Transaction Notes mainly from Chapter 13 of Coulouris.

Slides:



Advertisements
Similar presentations
CS6223: Distributed Systems
Advertisements

CS542: Topics in Distributed Systems Distributed Transactions and Two Phase Commit Protocol.
CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture X: Transactions.
COS 461 Fall 1997 Transaction Processing u normal systems lose their state when they crash u many applications need better behavior u today’s topic: how.
1 TRANSACTION & CONCURRENCY CONTROL Huỳnh Văn Quốc Phương Thái Thị Thu Thủy
Computer Science 425 Distributed Systems Lecture 21 Transaction Processing and Concurrency Control Reading: Sections
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg This material is made available for private study and for direct.
Lecture 11: Transactions and Concurrency Control Haibin Zhu, PhD. Assistant Professor Department of Computer Science Nipissing University © 2002.
Transactions Distributed Systems An introduction to Transaction Processing (TP), Two Phase Locking (2PL) and the Two Phase Commit Protocol.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
Computer Science Lecture 18, page 1 CS677: Distributed OS Last Class: Fault Tolerance Basic concepts and failure models Failure masking using redundancy.
Transactions Distributed Systems An introduction to Transaction Processing (TP), Two Phase Locking (2PL) and the Two Phase Commit Protocol.
CMPT Dr. Alexandra Fedorova Lecture X: Transactions.
Concurrency Control and Recovery In real life: users access the database concurrently, and systems crash. Concurrent access to the database also improves.
OCT Distributed Transaction1 Lecture 13: Distributed Transactions Notes adapted from Tanenbaum’s “Distributed Systems Principles and Paradigms”
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Distributed Snapshots –Termination detection Election algorithms –Bully –Ring.
Systems of Distributed Systems Module 2 -Distributed algorithms Teaching unit 3 – Advanced algorithms Ernesto Damiani University of Bozen Lesson 6 – Two.
Computer Science Lecture 17, page 1 CS677: Distributed OS Last Class: Fault Tolerance Basic concepts and failure models Failure masking using redundancy.
Transaction Management and Concurrency Control
Atomic TransactionsCS-502 Fall Atomic Transactions in Distributed Systems CS-502, Operating Systems Fall 2007 (Slides include materials from Operating.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
Transaction Management
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
1 More on Distributed Coordination. 2 Who’s in charge? Let’s have an Election. Many algorithms require a coordinator. What happens when the coordinator.
1 ICS 214B: Transaction Processing and Distributed Data Management Distributed Database Systems.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
Distributed Systems Fall 2009 Distributed transactions.
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Vector timestamps Global state –Distributed Snapshot Election algorithms.
Service Oriented Architecture Master of Information System Management Service Oriented Architecture Lecture 9 Notes from: Web Services & Contemporary.
Distributed Commit Dr. Yingwu Zhu. Failures in a distributed system Consistency requires agreement among multiple servers – Is transaction X committed?
CS162 Section Lecture 10 Slides based from Lecture and
Exercises for Chapter 16: Transactions and Concurrency Control
Service Oriented Architecture Master of Information System Management Service Oriented Architecture Notes from: Web Services & Contemporary SOA.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 10 Transaction Management.
Transactions Distributed Systems Introduction to Transaction Processing (TP) and the Two Phase Commit Protocol Notes adapted from: Coulouris:
Transaction Communications Yi Sun. Outline Transaction ACID Property Distributed transaction Two phase commit protocol Nested transaction.
Distributed Systems CS 425 / CSE 424 / ECE 428 Transactions & Concurrency Control  2010, I. Gupta, K. Nahrtstedt, S. Mitra, N. Vaidya, M. T. Harandi,
Distributed Transactions Chapter 13
Distributed Transactions
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Concurrency Control Steve Ko Computer Sciences and Engineering University at Buffalo.
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Vector timestamps Global state –Distributed Snapshot Election algorithms –Bully algorithm.
Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans.
Fault Tolerance CSCI 4780/6780. Distributed Commit Commit – Making an operation permanent Transactions in databases One phase commit does not work !!!
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
XA Transactions.
Distributed Transactions Chapter – Vidya Satyanarayanan.
Transactions and Concurrency Control. Concurrent Accesses to an Object Multiple threads Atomic operations Thread communication Fairness.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
CSC 240 (Blum)1 Database Transactions. CSC 240 (Blum)2 Transaction  A transaction is an interaction between a user (or application) and a database. A.
IM NTU Distributed Information Systems 2004 Distributed Transactions -- 1 Distributed Transactions Yih-Kuen Tsay Dept. of Information Management National.
A client transaction becomes distributed if it invokes operations in several different Servers There are two different ways that distributed transactions.
TRANSACTION & CONCURRENCY CONTROL 1. CONTENT 2  Transactions & Nested transactions  Methods for concurrency control  Locks  Optimistic concurrency.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
Fault Tolerance Chapter 7. Goal An important goal in distributed systems design is to construct the system in such a way that it can automatically recover.
Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database.
Distributed Transactions What is a transaction? (A sequence of server operations that must be carried out atomically ) ACID properties - what are these.
10-Jun-16COMP28112 Lecture 131 Distributed Transactions.
Chapter 13 Managing Transactions and Concurrency Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
Distributed Systems Learning Objectives
Distributed Systems An introduction to Transaction Processing (TP) and the Two Phase Commit Protocol Notes adapted from: Coulouris: Distributed.
Transactions and Concurrency Control
Chapter 10 Transaction Management and Concurrency Control
Slides for Chapter 14: Distributed transactions
Distributed Transactions
Distributed Transactions
Distributed Transactions
UNIVERSITAS GUNADARMA
Distributed Transactions
Distributed Transactions
Last Class: Fault Tolerance
Presentation transcript:

Transactions Distributed Systems Lecture 15: Transactions and Concurrency Control Transaction Notes mainly from Chapter 13 of Coulouris Distributed Transactions Notes adapted from Tanenbaum’s “Distributed Systems Principles and Paradigms”

Transactions A transaction is specified by a client as a set of operations on objects to be performed as an indivisible unit by the servers managing those objects. The servers must guarantee that either the entire transaction is carried out and the results recorded in permanent storage or, in the case that one or more of them crashes, its effects are completely erased Transactions 2

3 3 3 Transactions (ACID) Atomic: All or nothing. No intermediate states are visible. Consistent: system invariants preserved, e.g., if there were n dollars in a bank before a transfer transaction then there will be n dollars in the bank after the transfer. Isolated: Two transactions do not interfere with each other. They appear as serial executions. Durable: The commit causes a permanent change.

Recall The Synchronized Keyword private double balance; public synchronized void deposit(double amount) throws RemoteException { add amount to the balance } public synchronized void withdraw(double amount) throws RemoteException { subtract amount from the balance } Transactions 4 If one thread invokes a method it acquires a lock. Another thread will be blocked until the lock is released. These operations are atomic. This is all that is required for many applications.

Communicating Threads Consider a shared queue and two operations: synchronized first() { removes from front } synchronized append() { adds to rear } Is this sufficient? No. If the queue is empty the client of first() will have to poll on the method. It is also potentially unfair Transactions 5

Communicating Threads Consider again the shared queue and two operations: synchronized first() { if queue is empty call wait() remove from front } synchronized append() { adds to rear call notify() } Transactions 6 When threads can synchronize their actions on an object by means of wait and notify, the server holds on to requests that cannot immediately be satisfied and the client waits for a reply until another client has produced whatever they need. Note that both methods are synchronized. Only one thread at a time is allowed in. This is general. It can get tricky fast.

Back to Transactions A client may require that a sequence of separate requests to a server be atomic. - Free from interference from other concurrent clients. - Either all of the operations complete successfully or they have no effect at all in the presence of server crashes Transactions 7

Assume Each Operation Is Synchronized Client 1 Transaction T; a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200); Transactions 8 Client 2 Transaction W; total = a.getBalance(); total = total + b.getBalance(); total = total + c.getBalance(); Are we OK?

Assume Each Operation Is Synchronized Client 1 Transaction T; a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200); Transactions 9 Client 2 Transaction W; total = a.getBalance(); total = total + b.getBalance(); total = total + c.getBalance(); Inconsistent retrieval!

Assume Each Operation Is Synchronized Client 1 Transaction T; bal = b.getBalance(); b.setBalance(bal*1.1); Transactions 10 Client 2 Transaction W; bal = b.getBalance(); b.setBalance(bal*1.1); Are we OK?

Assume Each Operation Is Synchronized Client 1 Transaction T; bal = b.getBalance() b.setBalance(bal*1.1); Transactions 11 Client 2 Transaction W; bal = b.getBalance(); b.setBalance(bal*1.1); Lost Update!

Assume Each Operation Is Synchronized Transaction T; a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200); Transactions 12 The aim of any server that supports transactions is to maximize concurrency. So, transactions are allowed to execute concurrently if they would have the same effect as serial execution. Each transaction is created and managed by a coordinator.

Example Transaction T tid = openTransaction(); a.withdraw(tid,100); b.deposit(tid,100); c.withdraw(tid,200); b.deposit(tid,200); closeTransaction(tid) or abortTransaction(tid) Transactions 13 Coordinator Interface: openTransaction() -> transID closeTransaction(transID) -> commit or abort abortTransaction(TransID)

Transaction Life Histories Transactions 14 SuccessfulClient AbortsServer Aborts openTransaction operation ::: : closeTransactionabortTransactioncloseTransaction returns an abort from server

Transactions 15 Locks A lock is a variable associated with a data item and describes the status of that item with respect to possible operations that can be applied to that item. Generally, there is one lock for each item. Locks provide a means of synchronizing the access by concurrent transactions to the items. The server sets a lock, labeled with the transaction identifier, on each object just before it is accessed and removes these locks when the transaction has completed.

Transactions 16 Example: Binary Lock (1) Lock_Item(x) B: if(Lock(x) == 0) Lock(x) = 1 else { wait until Lock(x) == 0 and we are woken up. GOTO B } Now, a transaction is free to use x. Not interleaved with other code until this terminates or waits. In java, this would be a synchronized method.

Transactions 17 Master of Information System Management Example: Binary Lock(2) The transaction is done using x. Unlock_Item(x) Lock(x) = 0 if any transactions are waiting then wake up one of the waiting transactions. Not interleaved with other code. If this were java, this method would be synchronized.

Transactions 18 Master of Information System Management Locks Are Often Used To Support Concurrent Transactions Transaction T 1 Transaction T 2 Lock_Item(x) Lock_Item(y) T 1 uses x T 2 uses y Unlock_Item(x) Unlock_Item(y) If x differs from y these two transactions proceed concurrently. If both want to use x, one waits until the other completes.

Locks May Lead to Deadlock Transactions 19 Four Requirements for deadlock: (1) Resources need mutual exclusion. They are not thread safe. (2) Resources may be reserved while a process is waiting for more. (3) Preemption is not allowed. You can't force a process to give up a resource. (4) Circular wait is possible. X wants what Y has and Y wants what Z has but Z wants what X has. Solutions (short course): Prevention (disallow one of the four) Avoidance (study what is required by all before beginning) Detection and recovery (reboot if nothing is getting done)

Transactions 20 Deadlock Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

Transactions 21 Transactions May Be Distributed Begin transaction BookTrip book a plane from Qantas book hotel from Hilton book rental car from Hertz End transaction BookTrip The Two Phase Commit Protocol is a classic solution.

Transactions 22 Client Talks to a Coordinator BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client openTrans Unique Transaction ID TID Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. TID = openTransaction() Recoverable objects needed to rent a car. Any server

Transactions 23 Client Uses Services BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Call + TID plane.bookFlight(111,”Seat32A”,TID) Any server Recoverable objects needed to rent a car.

24 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Participants Talk to Coordinator The participant knows where the coordinator is because that information can be included in the TID (eg. an IP address.) The coordinator now has a pointer to the participant. The participant only calls join if it has not already done so. join(TID,ref to participant)

Transactions 25 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Suppose All Goes Well (1) OK returned Recoverable objects needed to rent a car.

26 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. Suppose All Goes Well (2) OK returned CloseTransaction(TID) Called Coordinator begins 2PC and this results in a GLOBAL COMMIT sent to each participant. Recoverable objects needed to rent a car.

27 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. This Time No Cars Available (1) OK returned NO CARS AVAIL abortTransaction(TID) called Recoverable objects needed to rent a car.

28 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. This Time No Cars Available (2) OK returned NO CARS AVAIL abortTransaction(TID) called Coordinator sends a GLOBAL_ABORT to all particpants Recoverable objects needed to rent a car.

29 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client ROLLBACK CHANGES This Time No Cars Available (3) OK returned NO CARS AVAIL abortTransaction(TID) abortTransaction Each participant Gets a GLOBAL_ABORT ROLLBACK CHANGES

Transactions 30 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. BookPlane Server Crashes After Returning ‘OK’ (1) OK returned Recoverable objects needed to rent a car.

31 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane Recoverable objects needed to book a hotel. BookPlane Server Crashes After Returning ‘OK’ (2) OK returned CloseTransaction(TID) Called Coordinator excutes 2PC: Ask everyone to vote. No news from the BookPlane Participant so multicast a GLOBAL ABORT Recoverable objects needed to rent a car.

32 BookTrip Coordinator BookPlane Participant BookHotel Participant BookRentalCar Participant Different servers BookTrip Client Recoverable objects needed to book a plane ROLLBACK BookPlane Server Crashes after returning ‘OK’ (3) OK returned CloseTransaction(TID) Called ROLLBACK GLOBAl ABORT ROLLBACK

Transactions 33 Two-Phase Commit Protocol BookTrip Coordinator BookPlane BookHotel BookRentalCar Phase 1 BookTrip coordinator sends a Vote_Request to each process. Each process returns a Vote_Commit or Vote_Abort. Vote_Request Vote Request Vote_Commit Vote Commit

34 Two-Phase Commit Protocol BookTrip Coordinator BookPlane BookHotel BookRentalCar Phase 2 BookTrip coordinator checks the votes. If every process votes to commit then so will the coordinator. In that case, it will send a Global_Commit to each process. If any process votes to abort the coordinator sends a GLOBAL_ABORT. Each process waits for a Global_Commit message before committing its part of the transaction. Global Commit ACK Global Commit ACK Global Commit ACK

Transactions 35 2PC Finite State Machine from Tanenbaum Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK State has already been saved to permanent storage. BookTrip CoordinatorParticipant

Transactions 36 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If waiting too long for a Vote-Request send a Vote-Abort

Transactions 37 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If waiting too long After Vote-request Send a Global-Abort

Transactions 38 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If waiting too long we can’t simply abort! We must wait until the coordinator recovers. We might also make queries on other participants.

Transactions 39 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If this process learns that another has committed then this process is free to commit. The coordinator must have sent out a Global-commit that did not get to this process.

Transactions 40 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK If this process learns that another has aborted then it too is free to abort.

Transactions 41 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK Suppose this process learns that another process is still in its init state. The coordinator must have crashed while multicasting the Vote-request. It’s safe for this process (and the queried process) to abort.

Transactions 42 2PC Blocks in Three Places Init wait Abort Commit Vote-request Vote-commit Global-commit Vote-abort Global-abort Init Ready Abort Commit Vote-request Vote-commit Vote-request Vote-abort Global-commit ACK Global-abort ACK Tricky case: If the queried processes are all still in their ready state what do we know? We have to block and wait until the Coordinator recovers.