Slides for Chapter 13 Distributed transactions From Coulouris

Slides for Chapter 13: Distributed transactions From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

Figure 13. 1 Distributed transactions (a) Flat transaction (b) Nested transactions M X T 11 X Client T Y T T 1 N T 12 T T 21 T 2 Client Y Z P T 22 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 2 Nested banking transaction X Client T 1 A a. withdraw(10) B b. withdraw(20) C c. deposit(10) D d. deposit(20) T Y T = open. Transaction open. Sub. Transaction a. withdraw(10); open. Sub. Transaction b. withdraw(20); open. Sub. Transaction c. deposit(10); open. Sub. Transaction d. deposit(20); close. Transaction T 2 Z T T 3 4 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 3 A distributed banking transaction join open. Transaction close. Transaction. participant A a. withdraw(4); join Branch. X T Client T = open. Transaction a. withdraw(4); c. deposit(4); b. withdraw(3); d. deposit(3); close. Transaction participant b. withdraw(T, 3); B join b. withdraw(3); Branch. Y participant Note: the coordinator is in one of the servers, e. g. Branch. X C c. deposit(4); D d. deposit(3); Branch. Z Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 4 Operations for two-phase commit protocol can. Commit? (trans)-> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote. do. Commit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. do. Abort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction. have. Committed(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction. get. Decision(trans) -> Yes / No Call from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 5 The two-phase commit protocol Phase 1 (voting phase): 1. The coordinator sends a can. Commit? request to each of the participants in the transaction. 2. When a participant receives a can. Commit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. Phase 2 (completion according to outcome of vote): 3. The coordinator collects the votes (including its own). (a) If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a do. Commit request to each of the participants. (b) Otherwise the coordinator decides to abort the transaction and sends do. Abort requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a do. Commit or do. Abort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a have. Committed call as confirmation to the coordinator. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 6 Communication in two-phase commit protocol Coordinator Participant step status 2 prepared to commit (uncertain) 4 committed 1 3 prepared to commit (waiting for votes) committed can. Commit? Yes do. Commit have. Committed done Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 7 Operations in coordinator for nested transactions open. Sub. Transaction(trans) -> sub. Trans Opens a new subtransaction whose parent is trans and returns a unique subtransaction identifier. get. Status(trans)-> committed, aborted, provisional Asks the coordinator to report on the status of the transaction trans. Returns values representing one of the following: committed, aborted, provisional. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 8 Transaction T decides whether to commit T 11 T 1 provisional commit (at X) T T provisional commit (at N) T 21 provisional commit (at N) T provisional commit (at P) 12 T 2 abort (at M) aborted (at Y) 22 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 9 Information held by coordinators of nested transactions Coordinator of transaction T T 1 T 2 T 11 T 12 , T 21 T 22 Child transactions T 1, T 2 T 11 , T 12 T 21 , T 22 Participant Provisional commit list T 1, T 12 yes no (aborted) T 12 but not T 21 , T 12 no (parent aborted)T 22 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Abort list T 11 , T 2 T 11

Figure 13. 10 can. Commit? for hierarchic two-phase commit protocol can. Commit? (trans, sub. Trans) -> Yes / No Call a coordinator to ask coordinator of child subtransaction whether it can commit a subtransaction sub. Trans. The first argument trans is the transaction identifier of top-level transaction. Participant replies with its vote Yes / No. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 10 can. Commit? for flat two-phase commit protoco can. Commit? (trans, abort. List) -> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote Yes / No. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 12 Interleavings of transactions U, V and W U d. deposit(10) V lock D b. deposit(10) a. deposit(20) b. withdraw(30) W lock A at X lock B at Y c. deposit(30) lock C at Z a. withdraw(20) wait at X wait at Y c. withdraw(20) wait at Z Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 13 Distributed deadlock (a) (b) W Held by D C A X Z Waits for W Waits for V Held by V U Waits for B Held by Y Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 U

Figure 13. 14 Local and global wait-for graphs local wait-for graph T U X local wait-for graph V global deadlock detector T T Y U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 V

Figure 13. 15 Probes transmitted to detect deadlock W W® U ® V ® W Held by Waits for Deadlock detected C A Z W® U ® V Waits for Initiation W® U V U Held by Y B Waits for Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 X

Figure 13. 16 Two probes initiated Waits for V Waits for T U W (c) detection initiated at object requested by W (b) detection initiated at object requested by T (a) initial situation Waits for T V T ®U T W U T®U®W®V T®U®W ®V® T W V ®V®T®U U W ®V W Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 W Waits for

Figure 13. 17 Probes travel downhill . . (a) V stores probe when U starts waiting (b) Probe is forwarded when V starts waiting W U V probe queue U ®V Waits for B W U®V V® W Waits for C U ®V V U®V Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 probe queue U Waits for B

Figure 13. 18 Types of entry in a recovery file Type of entry Description of contents of entry Object A value of an object. Transaction status Transaction identifier, transaction status ( prepared, committed aborted) and other status values used for the two-phase commit protocol. Intentions list Transaction identifier and a sequence of intentions, each of which consists of <identifier of object>, <position in recovery file of value of object>. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 19 Log for banking service P 0 P 1 P 2 P 3 P 4 P 5 P 6 Object: A Object: B Object: C Object: A Object: B Trans: T Object: C Object: B 100 200 300 80 220 prepared committed 278 242 <A, P 1> <B, P 2> P 0 P 3 Checkpoint Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 P 7 Trans: U prepared <C, P 5> <B, P 6> P 4 End of log

Figure 13. 20 Shadow versions Map at start Map when T commits A ®P 0 B ® P 0' A ®P 1 B ®P 2 C ® P 0" Version store P 0' P 0" 100 200 300 P 1 80 P 2 P 3 P 4 220 278 242 Checkpoint Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 21 Log with entries relating to two-phase commit protocol Trans: T Coord’r: T Trans: T prepared part’pant list: . . . committed prepared intentions list Trans: U Part’pant: U Trans: U Coord’r: . . uncertain committed intentions list Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 22 Recovery of the two-phase commit protocol Role Status Action of recovery manager Coordinator prepared Coordinator committed Participant uncertain Participant Coordinator prepared done No decision had been reached before the server failed. It sends abort. Transaction to all the servers in the participant list and adds the transaction status aborted in its recovery file. Same action for state aborted. If there is no participant list, the participants will eventually timeout and abort the transaction. A decision to commit had been reached before the server failed. It sends a do. Commit to all the participants in its participant list (in case it had not done so before) and resumes the two-phase protocol at step 4 (Fig 13. 5). The participant sends a have. Committed message to the coordinator (in case this was not done before it failed). This will allow the coordinator to discard information about this transaction at the next checkpoint. The participant failed before it knew the outcome of the transaction. It cannot determine the status of the transaction until the coordinator informs it of the decision. It will send a get. Decision to the coordinator to determine the status of the transaction. When it receives the reply it will commit or abort accordingly. The participant has not yet voted and can abort the transaction. No action is required. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 13. 23 Nested transactions top of stack T 11 T T 1 T 2 A 1 T 12 A 11 A 1 T 1 A 12 A 11 T 11 A 2 A 12 T 12 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 T 2