Distributed Systems

(2024-2025) – 2nd semester

Ch17
DISTRIBUTED TRANSACTIONS
Introduction
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
(atomicity)
◦ The 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.
In a nested transaction, the top-level transaction can open subtransactions,
and each subtransaction can open further subtransactions down to any depth
of nesting

Distributed transactions
(a) Flat transaction (b) Nested transactions
M
X
T11

X
Client T1 N
T Y
T 12
T
T
T21
T2
Client
Y
Z the nested transaction is more P
T22
efficient because requests can
be run in parallel - with
several servers,
A flat client transaction completes each of In the nested case, subtransactions
its requests before going on to the next one. at the same level can run
Therefore, each transaction accesses concurrently, so T1 and T2 are
servers’ objects sequentially concurrent.
 Flat and nested distributed transactions

The coordinator a 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 a request to a
coordinator on 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 in coordinator
 Flat and nested distributed transactions

Open Transaction goes to the coordinator

A distributed banking transaction

openTransaction join participant
A client’s banking closeTransaction
A a.withdraw(4);
transaction involves .
join
accounts A, B, C and BranchX
D at servers
T
BranchX, BranchY participant
and BranchZ Client
b.withdraw(T, 3);
B b.withdraw(3);

BranchY
Each server is shown with join
a participant, which joins participant
the transaction by C c.deposit(4);
invoking the join method D d.deposit(3);
in the Note:
coordinator
the coordinator is in one of the servers, e.g. BranchX
BranchZ
Note that the TID (T) is passed with each request e.g. withdraw(T,3)
 Flat and nested distributed transactions

The join operation

The interface for Coordinator
◦ It has 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.
 Atomic commit protocols
One-phase atomic commit protocol
◦ The coordinator tells the participants whether to commit or abort.
◦ The problem: this does not allow one of the servers to decide to
abort – it may have discovered a deadlock or it may have crashed
and been restarted.
Two-phase atomic commit protocol
◦ 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.
 Atomic commit protocols

Operations for two-phase commit

protocol
Participant interface
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.

Coordinator interface
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.
 Atomic commit protocols

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.
 Atomic commit protocols

Two-Phase Commit Protocol

1 canCommit? canCommit?

2
yes
no
3

doCommit

4 doAbort
 Concurrency control in distributed transactions

TimeOut Protocol
canCommit?
At step 2 and 3 no
commit decision
made.
no
OK to abort.
Coordinator will
either not collect
doAbort
all commit votes
or will vote for
abort.
 Concurrency control in distributed transactions

TimeOut Protocol
1 canCommit?
At step 4
• Cohort cannot
2 communicate with
yes coordinator
3 Coordinator
mayhave decided •Has decided, it just
doCommit
• Cohort must block picks up from where
4
until it left off
communication •A cohort that
re-established crashed after voting
• Might ask other commit, it must block
cohorts. until it discovers.
 Concurrency control in distributed transactions

Blocking
1 canCommit? canCommit?
Blocking can
occur if:
2
yes
•Coordinatoor
crashes. no
3
•Cohort cannot
doCommit communicate
4 with coordinator. doAbort
•Between 2 and 4
The TID of a subtransaction is an extension of its parent's TID, so that a
subtransaction can work out the TID of the top-level transaction.
The client finishes a set of nested transactions by calling closeTransaction or
abortTransacation in the top-level transaction.
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.
This is the interface of the coordinator of a subtransaction.
◦ It allows it to open further subtransactions
◦ It allows its subtransactions to enquire about its status A
subtransaction
Client starts by using OpenTransaction to open a top-level starts after its
parent and
transaction.
finishes before
◦ This returns a TID for the top-level transaction it.
◦ The TID can be used to open a subtransaction
◦ The subtransaction automatically joins the parent and a TID is returned.
 Transaction T decides whether
12
tooncommit
T has provisionally committed and T has aborted, but the fate of T
depends
11
its parent T and eventually on the top-level transaction, T.
1
12

T11 abort (at M)

T1 provisional commit (at X)

T T12 provisional commit (at N)

T21 provisional commit (at N)

T2 aborted (at Y)
T22 provisional commit (at P)

Although T21 and T22 have both provisionally committed, T2 has

aborted and this means that T21 and T22 must also abort.
Recall that
1. A parent can commit even if a subtransaction aborts.
2. If a parent aborts, then its subtransactions must abort.
Information held by coordinators
of nested transactions
➢Each coordinator has a list of its
subtransactions
➢At provisional commit, a subtransaction
reports its status and the status of its
descendents to its parent.
➢If a subtransaction aborts, it tells its
parent.