Transcript Figure 15.1 A distributed multimedia system

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
T11
X
Client
T
Y
T
T1
N
T 12
T
T
21
T2
Client
Y
P
Z
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 = openTransaction
openSubTransaction
a.withdraw(10);
openSubTransaction
b.withdraw(20);
openSubTransaction
c.deposit(10);
openSubTransaction
d.deposit(20);
closeTransaction
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
openTransaction
closeTransaction
participant
A
.
a.withdraw(4);
join
BranchX
T
Client
T = openTransaction
a.withdraw(4);
c.deposit(4);
b.withdraw(3);
d.deposit(3);
closeTransaction
participant
b.withdraw(T, 3);
B
join
b.withdraw(3);
BranchY
participant
Note: the coordinator is in one of the servers, e.g. BranchX
C
c.deposit(4);
D
d.deposit(3);
BranchZ
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
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. 3
© Addison-Wesley Publishers 2000
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.
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
step
status
2
prepared to commit
(uncertain)
4
committed
1
3
prepared to commit
(waiting for votes)
committed
canCommit?
Yes
doCommit
haveCommitted
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
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. 3
© Addison-Wesley Publishers 2000
Figure 13.8
Transaction T decides whether to commit
T
11
T1
provisional commit (at X)
T
T
provisional commit (at N)
T21
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
T1
T2
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
T 1, T 12
yes
yes
no (aborted)
no (aborted)
T 12 but not T 21
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
T2
T 11
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 13.10
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. 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
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
(a) initial situation
Waits for
V
Waits for
T
U
W
(c) detection initiated at object
requested by W
(b) detection initiated at object
requested by T
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
P0
P1
P2
P3
P4
P5
P6
Object:A Object:B Object:C Object:A Object:B Trans:T Trans:T
Object:C Object:B
100
200
300
80
220
prepared committed 278
242
<A, P1>
<B, P2>
P0
P3
Checkpoint
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
P7
Trans:U
prepared
<C, P5>
<B, P6>
P4
End
of log
Figure 13.20
Shadow versions
Map at start
Map when T commits
A P0
B  P 0'
A P1
B P2
C  P 0"
C  P 0"
Version store
P0
P0'
P0"
100
200
300
P1
80
P2
P3
P4
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
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
committed
Participant
uncertain
Participant
Coordinator
prepared
done
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.
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).
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.
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.
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
T11
T
T
A1
1
T12
T2
A11
A11
A1
T1
A12
A12
A11
T11
A2
A2
A12
T12
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
T2