Professional Documents
Culture Documents
Distributed Trans
Distributed Trans
Distributed Trans
Distributed transactions
X
Client T1 N
T T 12
Y
T
T
T
21
T2
Client
Y
P
Z
T
22
Flat transaction send out requests to different servers and each request is completed before client
goes to the next one. Nested transaction allows sub-transactions at the same level to execute
concurrently.
Figure:
Nested banking transaction
X
Client T A a.withdraw(10)
1
T
T = openTransaction Y
openSubTransaction T B b.withdraw(20)
2
a.withdraw(10);
openSubTransaction
b.withdraw(20); Z
openSubTransaction
c.deposit(10); T
3 C c.deposit(10)
openSubTransaction
d.deposit(20); T D d.deposit(20)
4
closeTransaction
Coordinator of a distributed transaction
coordinator
openTransaction join participant
closeTransaction
A a.withdraw(4);
.
join
BranchX
T
participant
b.withdraw(T, 3);
Client B b.withdraw(3);
T = openTransaction
join BranchY
a.withdraw(4);
c.deposit(4); participant
b.withdraw(3);
d.deposit(3); C c.deposit(4);
closeTransaction
D d.deposit(3);
Note: client invoke an operation b.withdraw(),
B will inform participant at BranchY to join coordinator. BranchZ
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
The two-phase commit protocol
Coordinator Participant
Consider when a participant has voted Yes and is waiting for the
coordinator to report on the outcome of the vote by telling it to
commit or abort.
Such a participant is uncertain and cannot proceed any further. The
objects used by its transaction cannot be released for use by other
transactions.
Participant makes a getDecision request to the coordinator to
determine the outcome. If the coordinator has failed, the participant
will not get the decision until the coordinator is replaced resulting in
extensive delay for participant in uncertain state.
Timeout are used since exchange of information can fail when one
of the servers crashes, or when messages are lost So process will
not block forever.
Performance of two-phase commit protocol
When a participant has voted Yes and is waiting for the coordinator to
report on the outcome of the vote, such participant is in uncertain
stage.
If the coordinator has failed, the participant will not be able to get the
decision until the coordinator is replaced, which can result in extensive
delays for participants in the uncertain state.
One alternative strategy is allow the participants to obtain a decision
from other participants instead of contacting coordinator.
However, if all participants are in the uncertain state, they will not get a
decision.