slides for chapter 13: distributed transactions from coulouris, dollimore and kindberg distributed...
TRANSCRIPT
Slides for Chapter 13: Distributed transactions
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 13.1Distributed transactions
Client
X
Y
Z
X
Y
M
NT1
T2
T11
Client
P
TT
12
T21
T22
(a) Flat transaction (b) Nested transactions
T
T
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.2Nested banking transaction
a.withdraw(10)
c.deposit(10)
b.withdraw(20)
d.deposit(20)
Client A
B
C
T1
T2
T3
T4
T
D
X
Y
Z
T = openTransaction
openSubTransactiona.withdraw(10);
closeTransaction
openSubTransactionb.withdraw(20);
openSubTransactionc.deposit(10);
openSubTransactiond.deposit(20);
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.3A 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.4Operations for two-phase commit protocol
canCommit?(trans)-> Yes / NoCall 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 confirm that it has committed the transaction.
getDecision(trans) -> Yes / NoCall 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.5The 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 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.6Communication in two-phase commit protocol
canCommit?
Yes
doCommit
haveCommitted
Coordinator
1
3
(waiting for votes)
committed
done
prepared to commit
step
Participant
2
4
(uncertain)
prepared to commit
committed
statusstepstatus
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.7Operations in coordinator for nested transactions
openSubTransaction(trans) -> subTransOpens a new subtransaction whose parent is trans and returns a unique subtransaction identifier.
getStatus(trans)-> committed, aborted, provisionalAsks 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.8Transaction T decides whether to commit
1
2
T11
T12
T22
T21
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. 3
© Addison-Wesley Publishers 2000
Figure 13.9Information held by coordinators of nested transactions
Coordinator oftransaction
Childtransactions
Participant Provisionalcommit list
Abort list
T T1, T2 yes T1, T12 T11, T2
T1 T11, T12 yes T1, T12 T11
T2 T21, T22 no (aborted) T2
T11 no (aborted) T11
T12, T21 T12 but notT21 T21, T12
T22 no (parent aborted)T22
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.10canCommit? for hierarchic two-phase commit protocol
canCommit?(trans, subTrans) -> Yes / NoCall a coordinator to ask coordinator of child subtransaction whether it can commit a subtransaction subTrans. 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.10canCommit? for flat two-phase commit protoco
canCommit?(trans, abortList) -> Yes / NoCall 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.12Interleavings 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 Xc.deposit(30) lock C
b.withdraw(30) wait at Y at Z
c.withdraw(20) wait at Z
a.withdraw(20) wait at X
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.13Distributed deadlock
D
Waits for
Waitsfor
Held by
Heldby
B Waits forHeld
by
X
Y
Z
Held by
W
UV
AC
W
V
U
(a) (b)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.14Local and global wait-for graphs
X
T U
Y
V TT
U V
local wait-for graph local wait-for graph global deadlock detector
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.15Probes transmitted to detect deadlock
V
Held by
W
Waits forHeld by
Waitsfor
Waits for
Deadlockdetected
U
C
A
B
Initiation
W U V W
W U
W U V
Z
Y
X
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.16Two probes initiated
(a) initial situation (b) detection initiated at object requested by T
U
T
V
W
Waits for
Waitsfor
V
W
U
T
T U W VT U W
T UWaits for
U
V
T
W
W V T W V T U
W V
Waitsfor
(c) detection initiated at object requested by W
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.17Probes travel downhill
.
(b) Probe is forwarded when V starts waiting(a) V stores probe when U starts waiting
U
W
Vprobequeue
U V
Waits forB
Waits forB
Waitsfor C
V WU V
VU V
U V U
W probequeue
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.18Types 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-phasecommit protocol.
Intentions list Transaction identifier and a sequence of intentions, each ofwhich consists of <identifier of object>, <position in recoveryfile 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.19Log for banking service
P0 P1 P2 P3 P4 P5 P6 P7
Object:A Object:B Object:C Object:A Object:B Trans:T Trans:T Object:C Object:B Trans:U100 200 300 80 220 prepared committed 278 242 prepared
<A, P1> <C, P5><B, P2> <B, P6>P0 P3 P4
CheckpointEnd
of log
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.20Shadow versions
Map at start Map when T commits
A P 0 A P 1B P 0 ' B P 2C P 0" C P 0"
P0 P0' P0" P1 P2 P3 P4
Version store 100 200 300 80 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.21Log 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’pantlist: . . .
committed prepared Coord’r: . . uncertain committed
intentionslist
intentionslist
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 No decision had been reached before the server failed. It sendsabortTransaction to all the servers in the participant list and adds thetransaction status aborted in its recovery file. Same action for stateaborted. If there is no participant list, the participants will eventuallytimeout and abort the transaction.
Coordinator committed A decision to commit had been reached before the server failed. Itsends a doCommit to all the participants in its participant list (in caseit 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 (incase this was not done before it failed). This will allow the coordinatorto discard information about this transaction at the next checkpoint.
Participant uncertain The participant failed before it knew the outcome of the transaction. Itcannot determine the status of the transaction until the coordinatorinforms it of the decision. It will send a getDecision to the coordinatorto determine the status of the transaction. When it receives the reply itwill 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. 3
© Addison-Wesley Publishers 2000
Figure 13.23Nested transactions
T
A1 A11 A12 A2
A1
T1 T11 T12 T2
A11
A11
A12
A12
A2
top of stack
T1
T2
T11
T12