Distributed Transactions

Distributed transactions

(a) Flat transaction (b) Nested transactions

M
X
T11

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

 Servers for a distributed transaction need to coordinate their

actions.
 A client starts a transaction by sending an openTransaction
request to a coordinator. The coordinator returns the TID to
the client. The TID must be unique (serverIP and number
unique to that server)
 Coordinator is responsible for committing or aborting it.
Each other server in a transaction is a participant.
Participants are responsible for cooperating with the
coordinator in carrying out the commit protocol, and keep
track of all recoverable objects managed by it.
 Each coordinator has a set of references to the participants.
Each participant records a reference to the coordinator.
 Figure:
A distributed banking 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

the coordinator is in one of the servers, e.g. BranchX

ATOMIC COMMIT PROTOCOL

An atomic commit protocol is a cooperative procedure

used by a set of servers involved in a distributed
transaction.

It enables the servers to reach a joint decision as to

whether a transaction can be committed or aborted.
One-phase atomic commit protocol

 A transaction comes to an end when the client requests

that a transaction be committed or aborted.
 Simple way is: coordinator to communicate the commit
or abort request to all of the participants in the
transaction and to keep on repeating the request until all
of them have acknowledged that they had carried it out.
 Inadequate because when the client requests a commit,
it does not allow a server to make a unilateral decision
to abort a transaction. E.g. deadlock avoidance may
force a transaction to abort at a server when locking is
used. So any server may fail or abort and client is not
aware.
Two-phase commit protocol

 Allow any participant to abort its part of a transaction.

Due to atomicity, the whole transaction must also be
aborted.
 In the first phase, each participant votes for the
transaction to be committed or aborted. Once voted to
commit, not allowed to abort it. So before votes to
commit, it must ensure that it will eventually be able to
carry out its part, even if it fails and is replaced.
 A participant is said to be in a prepared state if it will
eventually be able to commit it. So each participant
needs to save the altered objects in the permanent
storage device together with its status-prepared.
Two-phase commit protocol

 In the second phase, every participant in the

transaction carries out the joint decision. If any one
participant votes to abort, the decision must be to abort.
If all the participants vote to commit, then the decision is
to commit the transaction.

 The problem is to ensure that all of the participants vote

and that they all reach the same decision. It is an
example of consensus. It is simple if no error occurs.
However, it should work when servers fail, message lost
or servers are temporarily unable to communicate with
one another.
Two-phase commit protocol

 If the client requests abort, or if the transaction is

aborted by one of the participants, the coordinator
informs the participants immediately.

 It is when the client asks the coordinator to commit the

transaction that two-phase commit protocol comes into
use.

 In the first phase, the coordinator asks all the

participants if they are prepared to commit; and in the
second, it tells them to commit or abort the transaction.
Figure:
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
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:
Communication in two-phase commit protocol

Coordinator Participant

step status step status

canCommit?
1 prepared to commit
(waiting for votes) Yes 2 prepared to commit
3 committed doCommit (uncertain)
haveCommitted 4 committed
done
Two-phase commit protocol

 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

 Provided that all servers and communication channels do not fail,

with N participants
 N number of canCommit? Messages and replies
 Followed by N doCommit messages
 The cost in messages is proportional to 3N
 The cost in time is three rounds of message.
 The cost of haveCommitted messages are not counted, which can
function correctly without them- their role is to enable server to
delete stale coordinator information.
 Failure of Coordinator

 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.