1. Slides for Chapter 14: Distributed transactions
From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design
Edition 4, © Addison-Wesley 2005

2. Figure 14.1 Distributed transactions
(a) Flat transaction
(b) Nested transactions
Client X Y Z M N T 1 2 11 P 12 21 22
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

3. Figure 14.2 Nested banking transaction
a.withdraw(10) c .
deposit(10)
b.withdraw(20)
d.deposit(20)
Client A B C T 1 2 3 4 D X Y Z
T =
openTransaction
openSubTransaction
a.withdraw(10);
closeTransaction
b.withdraw(20);
c.deposit(10);
d.deposit(20);
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

4. Figure 14.3 A distributed banking transaction
BranchZ
BranchX
participant C D
Client
BranchY B A
join T
a.withdraw(4);
c.deposit(4);
b.withdraw(3);
d.deposit(3);
openTransaction
b.withdraw(T, 3);
closeTransaction
T =
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.4 © Pearson Education 2005

5. 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 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

6. 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 confirmation to the coordinator.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

7. Figure 14.6 Communication 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)
status
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

8. 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 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

9. Figure 14.8 Transaction T decides whether to commit2 T 11 12 22 21
abort (at M)
provisional commit (at N)
provisional commit (at X)
aborted (at Y)
provisional commit (at P)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

10. Figure 14.9 Information held by coordinators of nested transactions
Coordinator of
Child
Participant
Provisional
Abort list
transaction
transactions
commit list T T
, T
yes T
, T T
, T 1 2 1 12 11 2 T T
, T
yes T
, T T 1 11 12 1 12 11 T T
, T
no (aborted) T 2 21 22 2 T
no (aborted) T 11 11 T
, T T
but not T 12 21 12 21 T
, T 21 12 T
no (parent aborted) T 22 22
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

11. 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 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.4 © Pearson Education 2005

12. 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 © Pearson Education 2005

13. Figure 14.12 Interleavings of transactions U, V and W
d.deposit(10)
lock D
b.deposit(10)
lock B at Y
a.deposit(20)
lock A at X
c.deposit(30)
lock C at Z
b.withdraw(30)
wait at Y
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.4 © Pearson Education 2005

14. Figure 14.14 Distributed deadlock
Waits for
Waits
for
Held by
Held by B X Y Z W U V A C
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

15. Figure 14.14 Local and global wait-for graphsX T U Y V
local wait-for graph
global deadlock detector
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

16. Figure 14.15 Probes transmitted to detect deadlockV
Held by W
Waits for
Waits
for
Deadlock
detected U C A B
Initiation Z Y X
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

17. Figure 14.16 Two probes initiated
(a) initial situation
(b) detection initiated at object requested by T
(c) detection initiated at object requested by W U T V W
Waits for
Waits
for
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

18. Figure 14.17 Probes travel downhill
(a) V stores probe when U starts waiting
(b) Probe is forwarded when V starts waiting U W V
probe
queue
Waits for B
Waits
for C
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

19. 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 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.4 © Pearson Education 2005

20. Figure 14.19 Log for banking serviceP P P P P P P P 1 2 3 4 5 6 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
< A , P
>
< C , P
> 1 5
< B , P 2
>
< B , P 6
> P P 3 P 4
Checkpoint
End
of log
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

21. Figure 14.20 Shadow versions
Map at start
Map when T commits A P A P 1 B P ' B P 2 C P
" C P
" P P ' P
" P P P P 1 2 3 4
Version store
100
200
300 80
220
278
242
Checkpoint
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

22. 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 © Pearson Education 2005

23. 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 file. Same action for state
. If there is no participant list, the participants will eventually
timeout and abort the transaction.
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
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.
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.
The participant has not yet voted and can abort the transaction.
done
No action is required.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005

24. Figure 14.23 Nested transactions
top of stack
T11 T A A A A A A A 1 11 11 12 12 2 2 1 T T A A A 12 1 11 12 T 2 T T T T 1 11 12 2
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn.4 © Pearson Education 2005