Slides for Chapter 12 Transactions and Concurrency Control

Slides for Chapter 12: Transactions and Concurrency Control From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

Figure 12. 1 Operations of the Account interface deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account get. Balance() -> amount return the balance of the account set. Balance(amount) set the balance of the account to amount Operations of the Branch interface create(name) -> account create a new account with a given name look. Up(name) -> account return a reference to the account with the given name branch. Total() -> amount return the total of all the balances at the branch Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 2 A client’s banking transaction T: a. withdraw(100); b. deposit(100); c. withdraw(200); b. deposit(200); Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 3 Operations in Coordinator interface open. Transaction() -> trans; starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. close. Transaction(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. abort. Transaction(trans); aborts the transaction. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 4 Transaction life histories Successful open. Transaction operation Aborted by client Aborted by server open. Transaction operation server aborts transaction operation close. Transaction abort. Transaction operation ERROR reported to client Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 5 The lost update problem Transaction T : Transaction U: balance = b. get. Balance(); b. set. Balance(balance*1. 1); a. withdraw(balance/10) balance = b. get. Balance(); b. set. Balance(balance*1. 1); c. withdraw(balance/10) balance = b. get. Balance(); b. set. Balance(balance*1. 1); a. withdraw(balance/10) $200 balance = b. get. Balance(); $200 b. set. Balance(balance*1. 1); $220 c. withdraw(balance/10) $280 $220 $80 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 6 The inconsistent retrievals problem Transaction V: a. withdraw(100) b. deposit(100) a. withdraw(100); Transaction W: a. Branch. branch. Total() $100 total = a. get. Balance() $100 total = total+b. get. Balance() $300 total = total+c. get. Balance() b. deposit(100) $300 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 7 A serially equivalent interleaving of T and U Transaction T: balance = b. get. Balance() b. set. Balance(balance*1. 1) a. withdraw(balance/10) Transaction U: balance = b. get. Balance() b. set. Balance(balance*1. 1) c. withdraw(balance/10) balance = b. get. Balance() $200 b. set. Balance(balance*1. 1) $220 a. withdraw(balance/10) balance = b. get. Balance() $220 b. set. Balance(balance*1. 1) $242 c. withdraw(balance/10) $278 $80 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 8 A serially equivalent interleaving of V and W Transaction V: a. withdraw(100); b. deposit(100) Transaction W: a. Branch. branch. Total() a. withdraw(100); $100 b. deposit(100) $300 total = a. get. Balance() $100 total = total+b. get. Balance() $400 total = total+c. get. Balance(). . . Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

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

Figure 12. 10 A non-serially equivalent interleaving of operations of transactions T and U Transaction T: x = read(i) write(i, 10) write(j, 20) Transaction U: y = read(j) write(j, 30) z = read (i) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 11 A dirty read when transaction T aborts Transaction T: Transaction U: a. get. Balance() a. set. Balance(balance + 10) a. get. Balance() a. set. Balance(balance + 20) balance = a. get. Balance() $100 a. set. Balance(balance + 10) $110 balance = a. get. Balance() $110 a. set. Balance(balance + 20) $130 commit transaction abort transaction Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 12 Overwriting uncommitted values Transaction T: Transaction U: a. set. Balance(105) a. set. Balance(110) a. set. Balance(105) $100 $105 a. set. Balance(110) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 $110

Figure 12. 13 Nested transactions T : top-level transaction T 1 = open. Sub. Transaction T 2 = open. Sub. Transaction T 1 : commit T 2 : open. Sub. Transaction T 11 : T 12 : prov. commit open. Sub. Transaction T 21 : abort open. Sub. Transaction prov. commit T 211 : prov. commit Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 14 Transactions T and U with exclusive locks Transaction T: balance = b. get. Balance() b. set. Balance(bal*1. 1) a. withdraw(bal/10) Transaction U: Operations Locks Operations open. Transaction bal = b. get. Balance() lock B balance = b. get. Balance() b. set. Balance(bal*1. 1) c. withdraw(bal/10) Locks open. Transaction b. set. Balance(bal*1. 1) a. withdraw(bal/10) lock A close. Transaction unlock A, B bal = b. get. Balance() waits for T’s lock on B lock B b. set. Balance(bal*1. 1) c. withdraw(bal/10) lock C close. Transaction unlock B, C Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 15 Lock compatibility For one object Lock already set Lock requested read write none OK OK read OK wait write wait Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 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. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 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 Lock. Type lock. Type; // the current type public synchronized void acquire(Trans. ID trans, Lock. Type a. Lock. Type ){ while(/*another transaction holds the lock in conflicing mode*/) { try { wait(); }catch ( Interrupted. Exception e){/*. . . */ } } if(holders. is. Empty()) { // no TIDs hold lock holders. add. Element(trans); lock. Type = a. Lock. Type; } else if(/*another transaction holds the lock, share it*/ ) ){ if(/* this transaction not a holder*/) holders. add. Element(trans); } else if (/* this transaction is a holder but needs a more exclusive lock*/) lock. Type. promote(); } } Continues on next slide Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 17 continued public synchronized void release(Trans. ID trans ){ holders. remove. Element(trans); // set locktype to none notify. All(); } } // remove this holder Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 18 Lock. Manager class public class Lock. Manager { private Hashtable the. Locks; public void set. Lock(Object object, Trans. ID trans, Lock. Type lock. Type){ Lock found. Lock; synchronized(this){ // find the lock associated with object // if there isn’t one, create it and add to the hashtable } found. Lock. acquire(trans, lock. Type); } } // synchronize this one because we want to remove all entries public synchronized void un. Lock(Trans. ID trans) { Enumeration e = the. Locks. elements(); while(e. has. More. Elements()){ Lock a. Lock = (Lock)(e. next. Element()); if(/* trans is a holder of this lock*/ ) a. Lock. release(trans); } } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 19 Deadlock with write locks Transaction T Operations Locks a. deposit(100); write lock A Transaction U Operations Locks b. deposit(200) write lock B a. withdraw(200); waits for T’s b. withdraw(100) waits for U’s lock on B lock on A Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 20 The wait-for graph for Figure 12. 19 Held by Waits for A T U U T Waits for B Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Held by

Figure 12. 21 A cycle in a wait-for graph U T V Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 22 Another wait-for graph V T Held by T C W Held by U B Held by W V U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Waits for

Figure 12. 23 Resolution of the deadlock in Figure 15. 19 Transaction T Operations Locks a. deposit(100); write lock A Transaction U Operations Locks b. deposit(200) write lock B a. withdraw(200); waits for T’s b. withdraw(100) waits for U’s lock on B (timeout elapses) T’s lock on A becomes vulnerable, unlock A, abort T lock on A a. withdraw(200); write locks A unlock A, B Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 24 Lock compatibility (read, write and commit locks) For one object Lock already set Lock to be set none read OK write OK commit OK read OK OK wait write OK wait commit wait Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 25 Lock hierarchy for the banking example Branch A B C Account Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 26 Lock hierarchy for a diary Week Monday Tuesday Wednesday Thursday Friday time slots 9: 00– 10: 00– 11: 00– 12: 00– 13: 00– 14: 00– 15: 00– 16: 00 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 27 Lock compatibility table for hierarchic locks read Lock to be set write I-read I-write none OK OK read OK wait write wait I-read OK wait OK OK I-write wait OK OK For one object Lock already set Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Table on page 498 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 3. Ti must not write objects written by Tv and Tv must not write objects written by Ti Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

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

Page 499 -500 Validation of Transactions Backward validation of transaction Tv boolean valid = true; for (int Ti = start. Tn+1; Ti <= finish. Tn; Ti++){ if (read set of Tv intersects write set of Ti) valid = false; } Forward validation of transaction Tv boolean valid = true; for (int Tid = active 1; Tid <= active. N; 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. 3 © Addison-Wesley Publishers 2000

Figure 12. 29 Operation conflicts for timestamp ordering Rule Tc 1. write Ti read 2. write Tc must not write an object that has been written by any Ti where Ti >Tc this requires that Tc > write timestamp of the committed object. 3. read write Tc must not read an object that has been written by any Ti where. Ti >Tc this requires that Tc > write timestamp of the committed object. Tc must not write an object that has been read by any Ti where Ti >Tc this requires that Tc ≥ the maximum read timestamp of the object. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

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

Page 503 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. 3 © Addison-Wesley Publishers 2000

Page 504 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. 3 © Addison-Wesley Publishers 2000

Figure 12. 31 (b) T 3 read (a) T 3 read Key: read proceeds T 2 Selected Time T 2 Selected read proceeds Selected Ti Time Committed Ti (d) T 3 read (c) T 3 read T 1 T 4 Tentative read waits T 4 Time Transaction aborts object produced by transaction Ti (with write timestamp Ti) T 1 < T 2 < T 3 < T 4 Time Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 12. 32 Timestamps in transactions T and U Timestamps and versions of objects A B C RTS WTS {} S open. Transaction bal = b. get. Balance() b. set. Balance(bal*1. 1) RTS WTS {} S {T} open. Transaction bal = b. get. Balance() wait for T a. withdraw(bal/10) commit bal = b. get. Balance() b. set. Balance(bal*1. 1) c. withdraw(bal/10) S, T T T {U} T, U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 S, U

Figure 12. 33 Late write operation would invalidate a read T 3 read; T 1 T 3 write; T 2 T 5 read; T 4 write; T 3 T 5 T 3 Time T 1 < T 2 < T 3 < T 4 < T 5 Key: Ti Tk Committed Tentative object produced by transaction Ti (with write timestamp Ti and read timestamp Tk) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Back to Atomic Commitment Protocols The BIG Question: How to achieve failure atomicity in a distributed system? Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

The Two Generals Problem • RED army wins if both divisions attack simultaneously • BLUE army wins otherwise • Red generals must co-rodinate the time of attack Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

The Two Generals Problem • communication is only by means of messengers • messengers have to go through the valey captured by the BLUE • they do not always make it. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

The Two Generals Problem PROBLEM: • Design an algorithm that makes the RED divisions to attack sometimes. • when they attack they should attack at the same time. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Two General’s Problem Claim: There is no algorithm that guarantees that the REDs always attack simultaneously. Proof: Consider the algorithm that solves the problem and generates teh execution that produces the smallest number of messages. z Take the last message z The algorithm should work even if the last message never arrives z Change the Algorithm so that it does not send it. z This is a new algorithm that solves the problem and generates an even ”shorter” execution. Contradiction! Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Two General’s Problem Claim: There is no algorithm that guarantees that the REDs always attack simultaneously without exchanging messages. . z The previous proof was assuming that. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Two General’s Problem Claim: There is no algorithm that guarantees that the REDs always attack simultaneously without exchanging messages. . Proof: E 1 G 1(0) G 2(0) E 2 E 3 G 1(0) G 2(1) G 1(1) G 2(1) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Two General’s Problem Claim: There is no algorithm that guarantees that the REDs always attack simultaneously without exchanging messages. . Proof: As an excersice. Hint: E 1 and E 2 are indistinquishable for G 1 and E 2 and E 3 are indistinguishable for G 2. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000