Slides for Chapter 14: Distributed transactions - Chapter 14 slides

  Slides for Chapter 14: Distributed transactions From

  Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design

Edition 4, © Addison-Wesley 2005 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.1 Distributed transactions

  (a) Flat transaction (b) Nested transactions Client

  X Y Z

  X Y M N T ₁ T ₂ T ₁₁ Client P T T ₁₂ T ₂₁ T ₂₂ T T Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.2 Nested banking transaction a.withdraw(10)

  c .

  deposit(10) b.withdraw(20) d.deposit(20)

  Client

  A B C T

  1 T

  2 T

  3 T

  4 T D

  X Y Z

  T = openTransaction openSubTransaction

  a.withdraw(10); closeTransaction

  openSubTransaction

  b.withdraw(20); openSubTransaction c.deposit(10); openSubTransaction d.deposit(20);

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.3 A distributed banking transaction ..

  BranchZ BranchX participant participant

  C D Client

  BranchY B A participant join join join

  T

   a.withdraw(4); c.deposit(4); b.withdraw(3); d.deposit(3); openTransaction b.withdraw(T, 3); closeTransaction

  T = openTransaction a.withdraw(4); c.deposit(4); b.withdraw(3); d.deposit(3); closeTransaction

  Note: the coordinator is in one of the servers, e.g. BranchX Figure 14.4 Operations for two-phase commit protocol canCommit?(trans)-> Yes / No

  Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote.

  doCommit(trans)

  Call from coordinator to participant to tell participant to commit its part of a transaction.

  doAbort(trans)

  Call from coordinator to participant to tell participant to abort its part of a transaction.

  haveCommitted(trans, participant)

  Call from participant to coordinator to confrm that it has committed the transaction.

  getDecision(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.4 Figure 14.5 The two-phase commit protocol

  Phase 1 (voting phase):

  1. The coordinator sends a canCommit? request to each of the participants in the transaction.

  2. When a participant receives a canCommit? 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 doCommit request to each of the participants. (b) Otherwise the coordinator decides to abort the transaction and sends doAbort requests to all participants that voted Yes.

  4. Participants that voted Yes are waiting for a doCommit or doAbort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a haveCommitted call as confrmation to the coordinator. _{Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4} Figure 14.6 Communication in two-phase commit protocol

  Coordinator Participant step status step status canCommit? prepared to commit

  (waiting for votes)

  2 prepared to commit doCommit (uncertain)

  3 committed haveCommitted

  4 committed done

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 Figure 14.7 Operations in coordinator for nested transactions openSubTransaction(trans) -> subTrans

  Opens a new subtransaction whose parent is trans and returns a unique subtransaction identifer. getStatus(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.4

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.8 Transaction T decides whether to commit

  1

  11 T

  12 T

  22 T

  21 abort (at M) provisional commit (at N) provisional commit (at X) aborted (at Y) provisional commit (at N) provisional commit (at P)

  T T T

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  11 T

  22

  no (aborted)

  T

  2 T

  11

  no (aborted)

  T

  12 , T

  2 T

  21 T

  12

  but notT

  21 T

  21 , T

  12 T

  22

  no (parent aborted)T

  21 , T

  11 T

  Figure 14.9 Information held by coordinators of nested transactions

  1 , T

  Coordinator of transaction Child transactions

  Participant Provisional commit list Abort list

  T T

  1 , T

  2

  yes

  T

  12 T

  12 T

  11 , T

  2 T

  1 T

  11 , T

  12

  yes

  T

  1 , T

  22 Figure 14.10 canCommit? for hierarchic two-phase commit protocol canCommit?(trans, subTrans) -> Yes / No

  Call a coordinator to ask coordinator of child subtransaction whether it can commit a subtransaction

subTrans. The frst argument trans is the transaction

identifer 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.4

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.11 canCommit? for flat two-phase commit protoco canCommit?(trans, abortList) -> 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.4

  Figure 14.12 Interleavings of transactions U, V and W

  U

  V W d.deposit(10)

  lock D

  b.deposit(10)

  lock B

  a.deposit(20)

  lock A at Y at X

  c.deposit(30)

  lock C

  b.withdraw(30) wait at Y

  at Z

  c.withdraw(20) wait at Z a.withdraw(20) wait at X Figure 14.14 Distributed deadlock

  (a) (b)

  W W

  Waits for Held by D C

  A

  X Z

  V Held Held by by

  Waits for U

  V U Waits for

  B Held by _{Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4} Y Figure 14.14 Local and global wait-for graphs

  local wait-for graph local wait-for graph global deadlock detector

  T

  

V T

T U

  V U

Y

  X Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  

   V Z Y

  



   U

   U W

   W W

   V 

   U

  Figure 14.15 Probes transmitted to detect deadlock

  Initiation W

  U C A B

  Deadlock detected

  Waits for Waits for

  Waits for Held by

  V Held by W

  X Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.16 Two probes initiated

  U Waits for U ^{V T} W

  

  U W

  

  T

  

  V

  

  T W

  

  V

  

  W

  

T



  (a) initial situation (b) detection initiated at object requested by T (c) detection initiated at object requested by W

  W

  

  U

  

  V T

  

  W

  

  U

  

  Waits for ^V _W ^{U T} T

  U ^{T V} W Waits for

  V Waits for Figure 14.17 Probes travel downhill _ .

  (b) Probe is forwarded when V starts waiting (a) V stores probe when U starts waiting

  W

  W U V  probe

  V W queue Waits

  

  U

  for C U

  V 

  U Waits for

  V V Waits for

  probe B

  U

   V B

   U

   V  queue

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.18 Types of entry in a recovery file

  Type of entry Description of contents of entry Object A value of an object.

  

Transaction statusTransaction identifer, transaction status (prepared, committed

aborted) and other status values used for the two-phase commit protocol.

  Intentions list Transaction identifer and a sequence of intentions, each of which consists of <identifer of object>, <position in recovery fle of value of object>.

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  <B, P

  4 Checkpoint

  3 P

  P P

  6 >

  <B, P

  2 >

  <A, P 1 > <C, P 5 >

  Figure 14.19 Log for banking service P P

  7 Object:A Object:B Object:C Object:A Object:B Trans: T Trans: T Object: C Object: B Trans: U 100 200 300 80 220 prepared committed 278 242 prepared

  6 P

  5 P

  4 P

  3 P

  2 P

  1 P

  End of log Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  Figure 14.20 Shadow versions

  

Map at start Map when T commits

A P 0 A P 1 B P 0' B P 2 C P 0" C P 0"

  P P ' P " P

  1 P

  2 P

  3 P

  4 Version store

  100 200 300 80 220 278 242

    

   

  

Checkpoint

  Figure 14.21 Log with entries relating to two-phase commit protocol

  Trans:T Coord’r:T Trans:T Trans:U Part’pant:U Trans:U Trans: U prepared part’pant committed prepared Coord’r: . . uncertain committed list: . . . intentions intentions list list

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 Figure 14.22 Recovery of the two-phase commit protocol

  Role Status Action of recovery manager

  Coordinator prepared No decision had been reached before the server failed. It sends

  abortTransaction to all the servers in the participant list and adds the

  transaction status aborted in its recovery fle. Same action for state

  aborted. If there is no participant list, the participants will eventually timeout and abort the transaction.

  Coordinator committed A decision to commit had been reached before the server failed. It sends a doCommit 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). Participant committed The participant sends a haveCommitted 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. Participant uncertain 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 getDecision to the coordinator to determine the status of the transaction. When it receives the reply it will commit or abort accordingly. Participant prepared The participant has not yet voted and can abort the transaction. Coordinator done No action is required. _{Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4}

  Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4

  2 A

  2 T ₁₁ T

  1 T

  T

  2 top of stack

  12 A

  12 A

  11 A

  11 A

  12 T

  Figure 14.23 Nested transactions

  11 T

  1 T

  1 T

  2 A

  12 A

  11 A

  1 A

  T A

  12