18IT902 - DISTRIBUTED SYSTEMS

Module :2
Module Name: Processes and Synchronization
Topic : Distributed Transaction
Faculty : Dr.K.Sasi Kala Rani
www.skcet.ac.in
 Topics Covered
• Introduction
• Nested Banking Transaction
• Coordinator
• Distributed Banking Transaction
• One-phase atomic commit
protocol
• Two-phase commit protocol
⮚ Operation
⮚ Communication
⮚ Performance
• Failure of Coordinator
 Distributed Transactions
• Distributed transaction accesses objects managed by multiple
servers.
• When a distributed transaction comes to an end atomicity
property, requires that either all of the servers involved in the
same transaction commit the transaction or all of them abort.
Agreement among servers are necessary.
• Transaction recovery is to ensure that all objects are
recoverable. The values of the objects reflect all changes
made by committed transactions and none of those made by
aborted ones.
 Flat Transactions
• In a flat transaction, a client makes requests to more than one server
• Transaction T is a flat transaction that invokes operations on objects in
servers X, Y and Z.
• A flat client transaction completes each of its requests before going
on to the next one. Therefore, each transaction accesses servers’
objects sequentially.
 Nested Transactions

• In a nested transaction, the top-level transaction can open

subtransactions, and each subtransaction can open further
subtransactions down to any depth of nesting.
• Client transaction T that opens two subtransactions, T1 and T2, which
access objects at servers X and Y. The subtransactions T1 and T2
open further subtransactions T11, T12, T21, and T22, which access
objects at servers M, N and P.
Nested Transactions

• Subtransactions at the
same level can run
concurrently
• T1 and T2 are concurrent,
and as they invoke objects in
different servers, they can run
in parallel.
 Nested Transactions
• Consider a distributed transaction in which a client transfers $10
from account A to C and then transfers $20 from B to D.
• Accounts A and B are at separate servers X and Y and accounts
C and D are at server Z.
• Four requests (two deposits and two withdraws) can run in
parallel and the overall effect can be achieved with better
performance than a sequential transaction
Nested Transactions
T = openTransaction
openSubTransaction
a.withdraw(10);
openSubTransaction
b.withdraw(20);
openSubTransaction
c.deposit(10);
openSubTransaction
d.deposit(20);
closeTransaction
 Coordinator
• 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.
 Coordinator
• The interface for Coordinator provides an additional method, join, which
is used whenever a new participant joins the transaction
join(Trans, reference to participant) : Informs a coordinator that a new
participant has joined the transaction Trans.
The coordinator records the new participant in its participant list.
Coordinator
 Coordinator
• Banking transaction involves accounts A, B, C and D at servers
BranchX, BranchY and BranchZ.
• The client’s transaction, T, transfers $4 from account A to account C
and then transfers $3 from account B to account D.
• Each server with a participant, which joins the transaction by
invoking the join method in the coordinator.
• When the client invokes one of the methods in the transaction, for
example b.withdraw(T, 3), the object receiving the invocation (B at
BranchY, in this case) informs its participant object that the object
belongs to the transaction T.
 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.
 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.
 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.
 Operations for two-phase commit protocol
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.
 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.
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.
 Two-phase commit protocol
• 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
• 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.
 Summary
• The atomicity property requires that either all of the servers
involved in the same transaction commit the transaction or all of
them abort.
• Servers for a distributed transaction need to coordinate their
actions.
• Each coordinator has a set of references to the participants.
Each participant records a reference to the coordinator.
• One-phase atomic commit protocol - A transaction comes to an
end when the client requests that a transaction be committed or
aborted.
• Two-phase commit protocol - Phase 1 (voting phase), Phase 2
(completion according to outcome of vote):
 Video and Assessment Links
Lecture Video 2

Lecture Video 1
Lecture Video 3