Transactions and Concurrency Control

Figure 13.2 A client’s banking transaction Transaction T: a.withdraw(100); b.deposit(100); Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.3 Operations in Coordinator interface openTransaction() -> trans; starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. closeTransaction(trans) -> (commit, abort); ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted. abortTransaction(trans); aborts the transaction. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.4 Transaction life histories Successful Aborted by client Aborted by server openTransaction openTransaction openTransaction operation operation operation operation operation operation server aborts transaction operation operation operation ERROR reported to client closeTransaction abortTransaction If a transaction aborts for any reason (self abort or server abort), it must be guaranteed that future transaction will not see the its effect either in the object or in their copies in permanent storage. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Concurrency Control: the lost update problem Transaction T : balance = b.getBalance(); b.setBalance(balance*1.1); a.withdraw(balance/10) U c.withdraw(balance/10) balance = b.getBalance(); $200 $220 $80 $280 a, b and c initially have bank account balance are: 100, 200, and 300. T transfers an amount from a to b. U transfers an amount from c to b. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Concurrency Control: The inconsistent retrievals problem Transaction V : Transaction W : a.withdraw(100) aBranch.branchTotal() b.deposit(100) a.withdraw(100); $100 total = a.getBalance() $100 total = total+b.getBalance() $300 total = total+c.getBalance() b.deposit(100) $300 a, b accounts start with 200 both. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

We say it is a serially equivalent interleaving. Serial equivalence If these transactions are done one at a time in some order, then the final result will be correct. If we do not want to sacrifice the concurrency, an interleaving of the operations of transactions may lead to the same effect as if the transactions had been performed one at a time in some order. We say it is a serially equivalent interleaving. The use of serial equivalence is a criterion for correct concurrent execution to prevent lost updates and inconsistent retrievals. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.7 A serially equivalent interleaving of T and U Transaction T : balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) U c.withdraw(balance/10) balance = b.getBalance() $200 $220 $242 $80 $278 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Conflicting Operations When we say a pair of operations conflicts we mean that their combined effect depends on the order in which they are executed. E.g. read and write Three ways to ensure serializability: Locking Timestamp ordering Optimistic concurrency control Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.9 Read and write operation conflict rules Operations of different transactions Conflict Reason read No Because the effect of a pair operations does not depend on the order in which they are executed write Yes Because the effect of and a operation depends on the order of their execution Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Server can lock any object that is about to be used by a client. Locks A simple example of a serializing mechanism is the use of exclusive locks. Server can lock any object that is about to be used by a client. If another client wants to access the same object, it has to wait until the object is unlocked in the end. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.14 Transactions T and U with exclusive locks : Transaction U : balance = b.getBalance() balance = b.getBalance() b.setBalance(bal*1.1) b.setBalance(bal*1.1) a.withdraw(bal/10) c.withdraw(bal/10) Operations Locks Operations Locks openTransaction bal = b.getBalance() lock B openTransaction b.setBalance(bal*1.1) bal = b.getBalance() waits for T a.withdraw(bal/10) Lock A lock on B closeTransaction unlock A , B lock B b.setBalance(bal*1.1) c.withdraw(bal/10) lock C closeTransaction unlock B , C Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.15 Lock compatibility For one object Lock requested read write Lock already set none OK OK read OK wait write wait wait An object can be read and write. From the compatibility table, we know pairs of read operations from different transactions do not conflict. So a simple exclusive lock used for both read and write reduces concurrency more than necessary. (Many readers/Single writer) Rules; If T has already performed a read operation, then a concurrent transaction U must not write until T commits or aborts. If T already performed a write operation, then concurrent U must not read or write until T commits or aborts. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Shared Lock and Exclusive lock Locks must be obtained before read/write can begin If a transaction want to read and write the same object, it can either Obtain an X-lock before reading and unlock it immediately afterwards Obtain an S-lock before reading, then obtain an X-lock before writing. And unlock it immediately afterwards. Consider the following examples A1 <- Read(X) A1 <- A1 – k Write(X, A1) A2 <- Read(Y) A2 <- A2 + k Write(Y, A2) A1 <- Read(X) A1 <- A1* 1.01 Write(X, A1) A2 <- Read(Y) A2 <- A2 * 1.01 Write(Y, A2) T1 (Transfer) T2 (Dividend) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Two-phase locking -- motivation Ensure that T1 does not read/write anything that T2 read/write. Unrealistic to check in real life What is a sufficient condition then? Ensure T1 does not read/write anything after releasing the lock!  (basic) Two-phase locking

Two phase locking – definition The basic two-phase locking (2PL) protocol A transaction T must hold a lock on an item x in the appropriate mode before T accesses x. If a conflicting lock on x is being held by another transaction, T waits. Once T releases a lock, it cannot obtain any other lock subsequently. Note: a transaction is divided into two phases: A growing phase (obtaining locks) A shrinking phase (releasing locks) Claim : 2PL ensures conflict serializability

Two phase locking – Serializability Lock-point: the point where the transaction obtains all the locks With 2PL, a schedule is conflict equivalent to a serial schedule ordered by the lock-point of the transactions

2-phase locking -- example S-lock(X) A1 <- Read(X) A1 <- A1 – k X-lock(X) Write(X, A1) S-lock(Y) A2 <- Read(Y) A2 <- A2 + k X-lock(Y) Write(Y, A2) Unlock(X) Unlock(Y) S-lock(X) 1. S-lock(X) A1 <- Read(X) A1 <- A1* 1.01 X-lock(X) Write(X, A1) S-lock(Y) A2 <- Read(Y) A2 <- A2 * 1.01 X-lock(Y) Write(Y, A2) Unlock(Y) Unlock(X) T2 waits Lock point for T1 T2 waits Lock point for T2 T1 T2

Recoverability from aborts Servers must record the effect of all committed transactions and none of the effects of the aborted transactions. A transaction may abort by preventing it affecting other concurrent transactions if it does so. Two problems associated with aborting transactions that may occur in the presence of serially equivalent execution of transactions: Dirty reads Premature writes Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.11 A dirty read when transaction T aborts : Transaction U : a.getBalance() a.getBalance() a.setBalance(balance + 10) a.setBalance(balance + 20) balance = a.getBalance() $100 a.setBalance(balance + 10) $110 balance = a.getBalance() $110 a.setBalance(balance + 20) $130 commit transaction abort transaction Dirty reads caused by a read in one transaction U and an earlier unsuccessful write in another transaction T on the same object. T will be rolled back and restore the original a value, thus U will have seen a value that never existed. U is committed, so cannot be undone. U performs a dirty read. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.12 Premature Write: Overwriting uncommitted values Transaction T : Transaction U : a.setBalance(105) a.setBalance(110) $100 a.setBalance(105) $105 a.setBalance(110) $110 Premature write: related to the interaction between write operations on the same object belonging to different transactions. a. If U aborts and then T commit, we got a to be correct 105. Some systems restore value to “Before images” value for abort action, namely the value before all the writes of a transaction. a is 100, which is the before image of T’s write. 105 is the before image of U’s write. b. Consider if U commits and then T aborts, we got wrong value of 100. c. Similarly if T aborts then U aborts, we got 105, which is wrong and should be 100. So to ensure correctness, write operations must be delayed until earlier transactions that updated the same object have either committed or aborted.

Recover problem with 2PL X-lock(X) A1 <- Read(X) A1 <- A1 * 10 Write(X, A1) Unlock(X) Abort! Dirty Read problem! There is a gap between releasing locks and the decision to commit/abort Other transactions can still access data written by a uncomitted transaction X-lock(X) A2 <- Read(X) A2 <- A2 + 1 Write(X, A2) Unlock(X) Commit Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Strict two-phase Locking Protocol Because transaction may abort, strict execution are needed to prevent dirty reads and premature writes, which are caused by read or write to same object accessed by another earlier unsuccessful transaction that already performed an write operation. So to prevent this problem, a transaction that needs to read or write an object must be delayed until other transactions that wrote the same object have committed or aborted. Rule: Any locks applied during the progress of a transaction are held until the transaction commits or aborts. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Strict two-phase Locking Protocol Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.16 Use of locks in strict two-phase locking 1. When an operation accesses an object within a transaction: (a) If the object is not already locked, it is locked and the operation proceeds. (b) If the object has a conflicting lock set by another transaction, the transaction must wait until it is unlocked. (c) If the object has a non-conflicting lock set by another transaction, the lock is shared and the operation proceeds. (d) If the object has already been locked in the same transaction, the lock will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used.) 2. When a transaction is committed or aborted, the server unlocks all objects it locked for the transaction. A transaction with a read lock that is shared by other transactions cannot promote its read lock to a write lock, because write lock will conflict with other read locks.

Continues on next slide Figure 13.17 Lock class public class Lock { private Object object; // the object being protected by the lock private Vector holders; // the TIDs of current holders private LockType lockType; // the current type public synchronized void acquire(TransID trans, LockType aLockType ){ while(/*another transaction holds the lock in conflicing mode*/) { try { wait(); }catch ( InterruptedException e){/*...*/ } } if(holders.isEmpty()) { // no TIDs hold lock holders.addElement(trans); lockType = aLockType; } else if(/*another transaction holds the lock, share it*/ ) ){ if(/* this transaction not a holder*/) holders.addElement(trans); } else if (/* this transaction is a holder but needs a more exclusive lock*/) lockType.promote(); Continues on next slide Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

public synchronized void release(TransID trans ){ Figure 13.17 continued public synchronized void release(TransID trans ){ holders.removeElement(trans); // remove this holder // set locktype to none notifyAll(); } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Optimistic Concurrency Control Kung and Robinson [1981] identified a number of inherent disadvantages of locking and proposed an alternative optimistic approach to the serialization of transaction that avoids these drawbacks. Disadvantages of lock-based: Lock maintenance represents an overhead that is not present in systems that do not support concurrent access to shared data. Locking sometimes are only needed for some cases with low probabilities. The use of lock can result in deadlock. Deadlock prevention reduces concurrency severely. The use of timeout and deadlock detection is not ideal for interactive programs. To avoid cascading aborts, locks cannot be released until the end of the transaction. This may reduce the potential for concurrency. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Optimistic Concurrency Control It is based on observation that, in most applications, the likelihood of two clients’ transactions accessing the same object is low. Transactions are allowed to proceed as though there were no possibility of conflict with other transactions until the client completes its task and issues a closeTransaction request. When conflict arises, some transaction is generally aborted and will need to be restarted by the client. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Optimistic Concurrency Control Each transaction has the following phases: Working phase: Each transaction has a tentative version of each of the objects that it updates. This is a copy of the most recently committed version of the object. The tentative version allows the transaction to abort with no effect on the object, either during the working phase or if it fails validation due to other conflicting transaction. Several different tentative values of the same object may coexist. In addition, two records are kept of the objects accessed within a transaction, a read set and a write set containing all objects either read or written by this transaction. Read are performed on committed version ( no dirty read can occur) and write record the new values of the object as tentative values which are invisible to other transactions. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Optimistic Concurrency Control Validation phase: When closeTransaction request is received, the transaction is validated to establish whether or not its operations on objects conflict with operations of other transaction on the same objects. If successful, then the transaction can commit. If fails, then either the current transaction or those with which it conflicts will need to be aborted. Update phase: If a transaction is validated, all of the changes recorded in its tentative versions are made permanent. Read-only transaction can commit immediately after passing validation. Write transactions are ready to commit once the tentative versions have been recorded in permanent storage. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Validation of Transactions Validation uses the read-write conflict rules to ensure that the scheduling of a particular transaction is serially equivalent with respect to all other overlapping transactions- that is, any transactions that had not yet committed at the time this transaction started. Each transaction is assigned a number when it enters the validation phase (when the client issues a closeTransaction). Such number defines its position in time. A transaction always finishes its working phase after all transactions with lower numbers. That is, a transaction with the number Ti always precedes a transaction with number Tj if i < j. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Table on page 547 Serializability of transaction T with respect to transaction Ti Tv Ti Rule write read 1. Ti must not read objects written by Tv read write 2. Tv must not read objects written by Ti write write 3. Ti must not write objects written by Tv and Tv must not write objects written by Ti The validation test on transaction Tv is based on conflicts between operations in pairs of transaction Ti and Tv, for a transaction Tv to be serializable with respect to an overlapping transaction Ti, their operations must conform to the above rules. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.28 Validation of transactions Earlier committed transactions Working Validation Update T 1 v Transaction being validated 2 3 Later active active Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Validation Backward Validation: checks the transaction undergoing validation with other preceding overlapping transactions- those that entered the validation phase before it. Forward Validation: checks the transaction undergoing validation with other later transactions, which are still active. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Page 547-548 Validation of Transactions Backward validation of transaction Tv boolean valid = true; for (int Ti = startTn+1; Ti <= finishTn; Ti++){ if (read set of Tv intersects write set of Ti) valid = false; } Forward validation of transaction Tv for (int Tid = active1; Tid <= activeN; Tid++){ if (write set of Tv intersects read set of Tid) valid = false; Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Timestamp based concurrency control Each transaction is assigned a unique timestamp value when it starts, which defines its position in the time sequence of transactions. The basic timestamp ordering rule is based on operation conflicts and is very simple: A transaction’s request to write an object is valid only if that object was last read and written by earlier transactions. A transaction’s request to read an object is valid only if that object was last written by an earlier transaction. This rule assume that there is only one version of each object and restrict access to one transaction at a time. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Timestamp ordering Timestamps may be assigned from the server’s clock or a counter that is incremented whenever a timestamp value is issued. Each object has a write timestamp and a set of tentative versions, each of which has a write timestamp associated with it; and a set of read timestamps. The write timestamps of the committed object is earlier than that of any of its tentative versions, and the set of read timestamps can be represented by its maximum member. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Timestamp ordering Whenever a transaction’s write operation on an object is accepted, the server creates a new tentative version of the object with write timestamp set to the transaction timestamp. Whenever a read operation is accepted, the timestamp of the transaction is added to its set of read timestamps. When a transaction is committed, the values of the tentative version become the values of the object, and the timestamps of the tentative version become the write timestamp of the corresponding object. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.29 Operation conflicts for timestamp ordering Rule Tc Ti 1. write read must not an object that by any where this requires that ≥ the maximum read timestamp of the object. 2. written > this requires > write timestamp of the committed object. 3. > write timestamp of the committed object. Each request from a transaction is checked to see whether it conforms to the operation conflict rules. Conflict may occur when previous done operation from other transaction Ti is later than current transaction Tc. It means the request is submitted too late.

Figure 13.30 Write operations and timestamps (b) T3 write T Key: Before 2 Before T T 1 2 T i Committed After T T 2 3 After T T T 1 2 3 T i Time Time Tentative object produced by transaction Ti (c) T3 write (d) T3 write (with write timestamp Ti) Transaction T T T1<T2<T3<T4 Before 1 4 T aborts Before 4 After T T T After T 1 3 4 4 Time Time Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Page 551 Timestamp ordering write rule if (Tc ≥ maximum read timestamp on D && Tc > write timestamp on committed version of D) perform write operation on tentative version of D with write timestamp Tc else /* write is too late */ Abort transaction Tc Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Page 551 Timestamp ordering read rule if ( Tc > write timestamp on committed version of D) { let Dselected be the version of D with the maximum write timestamp ≤ Tc if (Dselected is committed) perform read operation on the version Dselected else Wait until the transaction that made version Dselected commits or aborts then reapply the read rule } else Abort transaction Tc Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.31 Read operations and timestamps (b) T3 read (a) T3 read Key: read read T T T 2 proceeds 2 4 proceeds T i Selected Committed Selected Time Time T (d) T3 read i (c) T3 read Tentative Transaction read waits object produced by transaction Ti (with write timestamp Ti) T1 < T2 < T3 < T4 T T T 1 2 4 aborts Selected Time Time Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

S<T<U Exercise Timestamps and versions of objects T U A B C RTS WTS {} S openTransaction bal = b.getBalance() b.setBalance(bal*1.1) a.withdraw(bal/10) commit c.withdraw(bal/10) S<T<U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Figure 13.32 Timestamps in transactions T and U Timestamps and versions of objects T U A B C RTS WTS {} S openTransaction bal = b.getBalance() {T} b.setBalance(bal*1.1) wait for T a.withdraw(bal/10) commit c.withdraw(bal/10) S, U T, U S, T {U} S<T<U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005

Distributed Transactions 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 for atomicity and consistency. 95-702 Transactions

Interacting with a coordinator 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) Coordinator Interface: openTransaction() -> transID closeTransaction(transID) -> commit or abort abortTransaction(TransID) Think about atomicity and consistency. 95-702 Transactions 48 95-702 Transactions

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

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

What is a Recoverable Object? Different servers BookPlane Participant Recoverable objects needed to book a plane BookHotel Participant A recoverable object follows the Golden Rule of Recoverability: Recoverable objects needed to book a hotel. BookRentalCar Participant Never modify the only copy. Recoverable objects needed to rent a car. The servers make changes to local copies of locked resources until a commit or rollback. 95-702 Transactions

Participants Talk to Coordinator The participant only calls join if it has not already done so. Different servers BookPlane Participant BookTrip Coordinator Recoverable objects needed to book a plane join(TID,ref to participant) BookHotel Participant Recoverable objects needed to book a hotel. BookRentalCar Participant BookTrip Client 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.

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

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

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

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

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

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

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

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

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

Two-Phase Commit Protocol BookPlane Global Commit BookTrip Coordinator ACK BookHotel Global Commit ACK Global Commit 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. ACK

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

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

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

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

2PC Blocks in Three Places 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. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort 95-702 Transactions

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

2PC Blocks in Three Places 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. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort 95-702 Transactions

2PC Blocks in Three Places 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. Init Init Vote-request ----------------- Vote-commit Commit ---------- Vote-request Vote-request ----------------- Vote-abort Ready wait Vote-abort -------------- Global-abort Vote-commit ---------------- Global-commit Global-commit ------------------- ACK Global-abort ---------------- ACK Commit Abort Commit Abort 95-702 Transactions

The transactions T and U are defined as follows: Exercises A server manages the objects a1, a2, ... an. The server provides two operations for its clients: read (i) returns the value of ai; write(i, Value) assigns Value to ai. The transactions T and U are defined as follows: T: x = read(j); y = read (i); write(j, 44); write(i, 33); U: x = read(k); write(i, 55); y = read (j); write(k, 66). Give three serially equivalent interleavings of the transactions T and U. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Addison-Wesley Publishers 2005