Chapter 13 Slides

Figure 13.
1 Distributed transactions
(a) Flat transaction (b) Nested transactions
X M
T
11
X
Client T1 N
T
Y T
12
T T
T
21
Client T
2
Y
Z P
T
22
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 ©Pearson Education 2001 1
Figure 13.2 Nested banking transaction
X
Client T1 A a.withdraw(10)
T
T = openTransaction
openSubTransaction Y
a.withdraw(10); T
2 B b.withdraw(20)
openSubTransaction
b.withdraw(20);
openSubTransaction Z
c.deposit(10);
openSubTransaction T C c.deposit(10)
3
d.deposit(20);
closeTransaction T D d.deposit(20)
4
Figure 13.3 A distributed banking transaction
coordinator
join participant
openTransaction
closeTransaction A a.withdraw(4);
.
join
BranchX
T participant
b.withdraw(T, 3);
Client B b.withdraw(3);
T = openTransaction
a.withdraw(4); join BranchY
c.deposit(4);
b.withdraw(3); participant
d.deposit(3); c.deposit(4);
closeTransaction C
D d.deposit(3);
BranchZ
Note: the coordinator is in one of the servers, e.g. BranchX
Figure 13.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 confirm 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.
Figure 13.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
confirmation to the coordinator.
Figure 13.6 Communication in two-phase commit protocol
Coordinator Participant
step status step status

1 prepared to commit canCommit?
(waiting for votes) Yes 2 prepared to commit
3 committed doCommit (uncertain)
haveCommitted 4 committed
done
Figure 13.7 Operations in coordinator for nested transactions
openSubTransaction(trans) → subTrans
Opens a new subtransaction whose parent is trans and returns a unique
subtransaction identifier.
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.
Figure 13.8 Transaction T decides whether to commit
T abort (at M)
11
T1 provisional commit (at X)
T T provisional commit (at N)

12
T 21 provisional commit (at N)

T aborted (at Y)
2
T provisional commit (at P)
22
Figure 13.9 Information held by coordinators of nested transactions:
Coordinator Child Participant Provisional Abort list

of transaction transactions commit 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 not T21 T21, T12
T22 no (parent aborted) T22
Figure 13.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 first argument trans is the transaction identifier of
top-level transaction. Participant replies with its vote Yes / No.
Figure 13.11 canCommit? for flat two-phase commit protocol
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.
Figure 13.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 13.13 Distributed deadlock
(a) (b)
W W
Held by Waits for
C D A
Z X
V
Held
Waits Held by by
for
V U U
B Waits for
Held
by
Y
Figure 13.14 Local and global wait-for graphs
local wait-for graph local wait-for graph global deadlock detector
T
T U V T
U V
X Y
Figure 13.15 Probes transmitted to detect deadlock
W
W→ U → V → W Held by Waits for
Deadlock
detected C
A
Z
Initiation X
W
Waits
→
for U
U
→
→
W
V
V
U
Held by Waits for

Y B
Figure 13.16 Two probes initiated
(a) initial situation (b) detection initiated at object (c) detection initiated at object
requested by T requested by W
Waits for T→ T
W
Waits for T T U → T
→
V
→
V
→
V U W
V
T
U
V
→
T
W
→
U
U→
U
U
→
W Waits
W
T→
W
→
for Waits
V
W W for
Figure 13.17 Probes travel downhill
(a) V stores probe when U starts waiting (b) Probe is forwarded when V starts waiting
W W U→V probe
Waits V→ W queue
U for C
U →V
U
V Waits for V Waits for

probe
U →V B U→V B
queue
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 identifier, transaction status (prepared, committed,
Transaction status aborted) – and other status values used for the two-phase commit
protocol.
Transaction identifier and a sequence of intentions, each of which
Intentions list consists of <identifier of object>, <position in recovery file of
value of object>.
Figure 13.19 Log 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:U
100 200 300 80 220 prepared committed 278 242 prepared
<A, P1> <C, P5>
<B, P2> <B, P6>
P0 P3 P4
Checkpoint End
of log
Figure 13.20 Shadow versions
Map at start Map when T commits

A → P0 A → P1
B → P0' B → P2
C → P0" C → P0"
P0 P0' P0" P1 P2 P3 P4
Version store 100 200 300 80 220 278 242
Checkpoint
Figure 13.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

part’pant
prepared committed prepared Coord’r: . . . uncertain committed
list: . . .
intentions intentions
list list
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 sends
abortTransaction 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.
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.
Figure 13.23 Nested transactions
top of stack
T11
T1 A1 A11 A11 A12 A12 A2 A2
T T12 A1 A11 A12
T2
T1 T11 T12 T2

Chapter 13 Slides

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 13 Slides

Uploaded by

Copyright:

Available Formats

Figure 13.

(a) Flat transaction (b) Nested transactions

Phase 1 (voting phase):

step status step status

T T provisional commit (at N)

T 21 provisional commit (at N)

Coordinator Child Participant Provisional Abort list

canCommit?(trans, subTrans) → Yes / No

Figure 13.11 canCommit? for flat two-phase commit protocol

canCommit?(trans, abortList) → Yes / No

Held by Waits for

V Waits for V Waits for

Type of entry Description of contents of entry

Map at start Map when T commits

Trans:T Coord’r:T • • Trans:T Trans:U • • Part’pant:U Trans:U Trans:U

Role Status Action of recovery manager

Coordinator done No action is required.

You might also like