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

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

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 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 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. 3 © Addison-Wesley Publishers 2000 Figure 12.4 Transaction life histories SuccessfulAborted by clientAborted by server openTransaction operation server aborts transaction operation operation ERROR reported to client closeTransactionabortTransaction

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 TransactionT: balance = b.getBalance(); b.setBalance(balance*1.1); a.withdraw(balance/10) TransactionU: balance = b.getBalance(); b.setBalance(balance*1.1); c.withdraw(balance/10) balance = b.getBalance(); $200 balance = b.getBalance(); $200 b.setBalance(balance*1.1); $220 b.setBalance(balance*1.1); $220 a.withdraw(balance/10) $80 c.withdraw(balance/10) $280

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 TransactionV: a.withdraw(100) b.deposit(100) TransactionW : aBranch.branchTotal() a.withdraw(100); $100 total = a.getBalance() $100 total = total+b.getBalance() $300 total = total+c.getBalance() 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 TransactionT: balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) TransactionU: balance = b.getBalance() b.setBalance(balance*1.1) c.withdraw(balance/10) balance = b.getBalance()$200 b.setBalance(balance*1.1)$220 balance = b.getBalance()$220 b.setBalance(balance*1.1)$242 a.withdraw(balance/10) $80 c.withdraw(balance/10)$278

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 TransactionV: a.withdraw(100); b.deposit(100) TransactionW: aBranch.branchTotal() a.withdraw(100); $100 b.deposit(100) $300 total = a.getBalance() $100 total = total+b.getBalance() $400 total = total+c.getBalance()...

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 transactions ConflictReason read NoBecause the effect of a pair ofread operations does not depend on the order in which they are executed readwriteYesBecause the effect of aread and awrite operation depends on the order of their execution write YesBecause the effect of a pair ofwrite 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 A non-serially equivalent interleaving of operations of transactions T and U TransactionT: U: x = read(i) write(i, 10) y = read(j) write(j, 30) write(j, 20) z = read (i)

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure A dirty read when transaction T aborts TransactionT: a.getBalance() a.setBalance(balance + 10) TransactionU: a.getBalance() 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

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Overwriting uncommitted values TransactionT: a.setBalance(105) TransactionU: a.setBalance(110) $100 a.setBalance(105)$105 a.setBalance(110)$110

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

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Transactions T and U with exclusive locks

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Lock compatibility For one objectLock requested readwrite Lock already set noneOK readOKwait writewait

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 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 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. 3 © Addison-Wesley Publishers 2000 Figure 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. 3 © Addison-Wesley Publishers 2000 Figure LockManager class public class LockManager { private Hashtable theLocks; public void setLock(Object object, TransID trans, LockType lockType){ Lock foundLock; synchronized(this){ // find the lock associated with object // if there isn’t one, create it and add to the hashtable } foundLock.acquire(trans, lockType); } // synchronize this one because we want to remove all entries public synchronized void unLock(TransID trans) { Enumeration e = theLocks.elements(); while(e.hasMoreElements()){ Lock aLock = (Lock)(e.nextElement()); if(/* trans is a holder of this lock*/ ) aLock.release(trans); }

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Deadlock with write locks TransactionT U OperationsLocksOperationsLocks a.deposit(100); write lockA b.deposit(200) write lockB b.withdraw(100) waits forU’sa.withdraw(200);waits forT’s lock onB A

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

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

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

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Resolution of the deadlock in Figure Transaction TTransaction U OperationsLocksOperationsLocks a.deposit(100); write lock A b.deposit(200) write lock B b.withdraw(100) waits for U ’s a.withdraw(200); waits for T’s lock onB A (timeout elapses) T’s lock onA becomes vulnerable, unlockA, abort T a.withdraw(200); write locksA unlockA, B

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Lock compatibility (read, write and commit locks) For one objectLock to be set readwritecommit Lock already setnoneOK readOK wait writeOKwait commitwait

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

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Lock hierarchy for a diary Week MondayTuesdayWednesdayThursdayFriday 9:00–10:00 time slots 10:00–11:0011:00–12:0012:00–13:0013:00–14:0014:00–15:0015:00–16:00

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

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 T i TvTv TiTi Rule writeread1.TiTi must not read objects written byTvTv readwrite2.TvTv must not read objects written byTiTi write 3.TiTi must not write objects written byTvTv and TvTv mustnot write objects written byTiTi

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

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

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Operation conflicts for timestamp ordering Rule TcTc TiTi 1.writereadTcTc must notwrite an object that has beenread by anyTiTi where this requires thatTcTc ≥ the maximum read timestamp of the object. 2.write TcTc must notwrite an object that has beenwritten by anyTiTi where TiTi >TcTc this requires thatTcTc > write timestamp of the committedobject. 3.readwriteTcTc must notread an object that has beenwritten by anyTiTi where this requires thatTcTc > write timestamp of the committed object. TiTi >TcTc TiTi >TcTc

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Write operations and timestamps

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

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 ( T c > write timestamp on committed version of D) { let D selected be the version of D with the maximum write timestamp ≤ T c if (D selected is committed) perform read operation on the version D selected else Wait until the transaction that made version D selected commits or aborts then reapply the read rule } else Abort transaction T c

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

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure Timestamps in transactions T and U Timestamps and versions of objects TUABC RTSWTSRTSWTSRTSWTS {}S S S openTransaction bal = b.getBalance() {T}{T} openTransaction b.setBalance(bal*1.1) bal = b.getBalance() wait for T a.withdraw(bal/10) commitTT bal = b.getBalance() b.setBalance(bal*1.1) c.withdraw(bal/10)S, U T, U S, T {U}{U}

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

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

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

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

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

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. zTake the last message zThe algorithm should work even if the last message never arrives zChange the Algorithm so that it does not send it. zThis 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.. zThe 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: Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 E1 G1(0) G2(0) E2 E3 G2(1) G1(0) G2(1) G1(1)

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: E1 and E2 are indistinquishable for G1 and E2 and E3 are indistinguishable for G2. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000