DISTRIBUTED

TRANSACTIONS
Flat and Nested
 Committing a Distributed Transaction

◦ A distributed transaction refers to a flat or nested

transaction that accesses objects managed by multiple servers
◦ When a distributed transaction comes to an end
◦ Either all of the servers commit the transaction
◦ Or all of them abort the transaction.
◦ One of the servers is coordinator, it must ensure the same
outcome at all of the servers.
◦ The ‘TWO-PHASE COMMIT PROTOCOL (2PCP)’ is
the most commonly used protocol for achieving this.

May 2018 Distributed Transactions 2

 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

May 2018 Distributed Transactions 3

 Distributed Transactions
In a nested transaction, the top-level
transaction can open sub-transactions, and
each sub-transaction can open further sub-
transactions down to any depth of nesting
M
X
T11

X
Client T1 N
T T 12
Y
T
T
T
In the nested case, sub-transactions at the same 21
T2
level can run concurrently,Client
so T1 and T2 are
concurrent, and as they invoke objects in
different servers, they can run in parallel. Y
P
Z
T
22
A flat client transaction completes each of its requests
before going on to the next one. Therefore, each transaction
May 2018 accesses
Distributed servers’ objects sequentially
Transactions 4
 Nested Banking Transaction
client transfers $10 from A to C and then transfers $20 from B to D
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 (T)
May 2018 Distributed Transactions 5
 Nested Banking Transaction
client transfers $10 from A to C and then transfers $20 from B to C
X
Requests can be run in Client T A a.withdraw(10)
parallel - 1
with several servers, the T
nested transaction is
more efficient

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 (T)
May 2018 Distributed Transactions 6
 The Coordinator of a Flat
Distributed Transaction
◦ Servers execute requests in a distributed transaction
◦ When it commits they must communicate with one another to
coordinate their actions
◦ A client starts a transaction by sending an openTransaction request
to a coordinator in any server
◦ It returns a TID unique in the distributed system(e.g. server ID + local transaction
number)
◦ At the end, it will be responsible for committing or aborting it
◦ Each server managing an object accessed by the transaction is a
participant - it joins the transaction
◦ A participant keeps track of objects involved in the transaction
◦ At the end it cooperates with the coordinator in carrying out the commit protocol
◦ Note that a participant can call abortTransaction
May 2018 Distributed Transactions 7
 A Flat Distributed Banking
Transaction
openTransaction join participant
closeTransaction
A a.withdraw(4);
.
join
Branch X
T
participant
b.withdraw(T, 3);
Client B b.withdraw(3);

T = openTransaction
join Branch Y
a.withdraw(4);
c.deposit(4); participant
b.withdraw(3);
d.deposit(3); C c.deposit(4);
closeTransaction
D d.deposit(3);
Note: the coordinator is in one of the servers, e.g. BranchX
Branch Z
Note that the TID (T) is passed with each request e.g. withdraw(T,3)
May 2018 Distributed Transactions 8
 openTransaction goes to the coordinator
A Flat Distributed Banking
Transaction join
openTransaction participant
closeTransaction
A client’s (flat) banking A a.withdraw(4);
transaction involves .
accounts A, B, C and join
D at servers Branch X, Branch X
Branch Y and Branch
Z T
participant
b.withdraw(T, 3);
Client B b.withdraw(3);

T = openTransaction
join Branch Y
a.withdraw(4);
c.deposit(4); Each server is shown with a
participant, which joins the participant
b.withdraw(3);
d.deposit(3); transaction by invoking the join c.deposit(4);
method in the coordinator C
closeTransaction
D d.deposit(3);
Note: the coordinator is in one of the servers, e.g. BranchX
Branch Z

May 2018
Note that the TID (T) isDistributed
passed with each request e.g. withdraw(T,3)
Transactions 9
 The Join Operation
◦ The interface for Coordinator includes
◦ openTransaction, closeTransaction and abortTransaction
◦ openTransaction returns a TID which is passed with each operation so that servers
know which transaction is accessing its objects
◦ The Coordinator interface 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.
◦ The fact that the coordinator knows all the participants and each participant knows
the coordinator will enable them to collect the information that will be needed at
commit time.

May 2018 Distributed Transactions 10

 May 2018

ATOMIC COMMIT
PROTOCOLS
1PCP & 2PCP
Distributed Transactions 11
 Atomic Commit Protocols
◦ Transaction atomicity requires that at the end,
◦ Either all of its operations are carried out or none of them.

◦ In a distributed transaction, the client has requested the operations at more

than one server
◦ ONE-PHASE ATOMIC COMMIT PROTOCOL (1PCP)
◦ The coordinator tells the participants whether to commit or abort
◦ This does not allow one of the servers to decide to abort – it may have discovered a deadlock or
it may have been crashed and restarted
◦ TWO-PHASE ATOMIC COMMIT PROTOCOL (2PCP)
◦ Is designed to allow any participant to choose to abort a transaction
◦ Phase 1 - each participant votes. If it votes to commit, it is prepared. It cannot change its mind.
In case it crashes, it must save updates in permanent store
◦ Phase 2 - the participants carry out the joint decision
The decision could be commit or abort - participants record it in permanent store
May 2018 Distributed Transactions 12
 Failure Model for the Commit
Protocols
◦ Recall the failure model for transactions
◦ i.e., dirty read, premature write, lost update and inconsistent retrieval
◦ These apply to the two-phase commit protocol
◦ Commit protocols are designed to work in
◦ Asynchronous system (e.g. messages may take a very long time)
◦ Servers may crash
◦ Messages may be lost.
◦ Assume corrupt and duplicated messages are removed.
◦ No Byzantine faults – servers either crash or they obey their requests

May 2018 Distributed Transactions 13

 2PCP
◦ During the progress of a transaction, the only communication between
coordinator and participant is the join request
◦ The client request to commit or abort goes to the coordinator
◦ If client or participant request abort, the coordinator informs the participants
immediately
◦ If the client asks to commit, the 2PC comes into use
◦ 2PCP
◦ Voting phase: coordinator asks all participants if they can commit
◦ If yes, participant records updates in permanent storage and then votes
◦ Completion phase: coordinator tells all participants to commit or abort

May 2018 Distributed Transactions 14

 Operations for Two Phase
Commit Protocol
This is a request with a reply
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. These are asynchronous requests to avoid delays
doAbort(trans)
Call from coordinator to participant to tell participant to abort its part of a transaction.
haveCommitted(trans, participant)
Call from participant to coordinatorAsynchronous
to confirm thatrequest
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.

participant interface- canCommit?, doCommit, doAbort

coordinator interface- haveCommitted, getDecision

May 2018 Distributed Transactions 15

 2PCP
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.

May 2018 Distributed Transactions 16

 2PCP

May 2018 Distributed Transactions 17

 2PCP

May 2018 Distributed Transactions 18

 Communication in 2PCP
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

◦ Time-out actions in the 2PCP: to avoid blocking forever when a process

crashes or a message is lost
◦ uncertain participant (step 2) has voted yes. it can’t decide on its own
◦ It uses getDecision method to ask coordinator about outcome
◦ participant has carried out client requests, but has not had a Commit?from the coordinator. It can
abort unilaterally
◦ coordinator delayed in waiting for votes (step 1). It can abort and send doAbort to participants.

May 2018 Distributed Transactions 19

 May 2018

CONCURRENCY
CONTROL IN
DISTRIBUTED
TRANSACTIONS
Locking
Distributed Transactions 20
 Concurrency Control in
Distributed Transactions
◦ Each server manages a set of objects and is responsible for
ensuring that they remain consistent when accessed by
concurrent transactions
◦ Therefore, each server is responsible for applying concurrency control to
its own objects.
◦ The members of a collection of servers of distributed transactions are
jointly responsible for ensuring that they are performed in a serially
equivalent manner
◦ Therefore if transaction T is before transaction U in their conflicting
access to objects at one of the servers then they must be in that order at all
of the servers whose objects are accessed in a conflicting manner by both
T and U

May 2018 Distributed Transactions 21

 Locking
◦ In a distributed transaction, the locks on an object
are held by the server that manages it.
◦ The local lock manager decides whether to grant a lock or make the
requesting transaction wait.
◦ It cannot release any locks until it knows that the transaction has
been committed or aborted at all the servers involved in the
transaction.
◦ The objects remain locked and are unavailable for other transactions
during the atomic commit protocol
◦ An aborted transaction releases its locks after phase 1 of the protocol.

May 2018 Distributed Transactions 22

 Interleaving of Transactions T
and U at Servers X and Y
◦ We have: T before U at server X and U before T at server Y
◦ Different orderings lead to cyclic dependencies and distributed
deadlock
◦ Detection and resolution of distributed deadlock
T U
Write(A) at X locks A

Write(B) at Y locks B

Read(B) at Y waits for U

Read(A) at X waits for T

May 2018 Distributed Transactions 23

 Distributed Deadlocks
◦ Single server transactions can experience deadlocks
◦ Prevent or detect and resolve
◦ Use of timeouts is clumsy, detection is preferable.
◦ It uses wait-for graphs.

◦ Distributed transactions lead to distributed

deadlocks
◦ In theory can construct global wait-for graph from local ones
◦ A cycle in a global wait-for graph that is not in local ones is a
distributed deadlock

May 2018 Distributed Transactions 24

 Interleaving of Transactions U, V
and W
objects A, B managed by X and Y ; C and D by Z

U V W
d.deposit(10) lock D
U  V at Y b.deposit(10) lock B
a.deposit(20) lock A at Y
V  W at Z W  U at X
at X
c.deposit(30) lock C
b.withdraw(30) wait at Y at Z

c.withdraw(20) wait at Z
a.withdraw(20) wait at X

May 2018 Distributed Transactions 25

 Distributed Deadlock
a deadlock cycle has alternate edges showing wait-for and held-by
wait-for added in order: U  V at Y; V  W at Z and W  U at X
W
W
Held by Waits for

C D A

Z X V

Held
Waits Held by by
for U
V U

B Waits for
Held
by •
May 2018 Distributed Transactions 26
Y
 Deadlock Detection - Local WAIT-
FOR GRAPHS
◦ Local wait-for graphs can be built, e.g.
◦ server Y: U  V added when U requests b.withdraw(30)
◦ server Z: V  W added when V requests c.withdraw(20)
◦ server X: W  U added when W requests a.withdraw(20)
◦ To find a global cycle, communication between the servers is needed
◦ CENTRALIZED DEADLOCK DETECTION
◦ One server takes on role of global deadlock detector
◦ The other servers send it their local graphs from time to time
◦ It detects deadlocks, makes decisions about which transactions to abort and informs the
other servers
◦ Usual problems of a centralized service - poor availability, lack of fault tolerance and no
ability to scale
◦ Other alternate is when the local graphs are shared with each other and global graph
is created at each participant. A participant can volunteer to release locks.

May 2018 Distributed Transactions 27

 Local and Global WAIT-FOR
GRAPHS
◦ PHANTOM DEADLOCKS
◦ a ‘deadlock’ that is detected, but is not really one
◦ happens when there appears to be a cycle, but one of the transactions
has released a lock, due to time lags in distributing graphs
◦ in the figure suppose U releases the object at X then waits for V at Y
◦ and the global detector gets Y’s graph before X’s (T  U  V  T)

May 2018 Distributed Transactions 28

 Local and Global WAIT-FOR
GRAPHS

local wait-for graph local wait-for graph global deadlock detector

T
T U V T

U V
X Y

May 2018 Distributed Transactions 29