1. Distributed Transactions
1. Introduction
2. Flat and nested distributed transactions
3. Atomic commit protocols
4. Concurrency control in distributed
transactions
5. Distributed deadlocks
6. Transaction recovery

2. 4. Concurrency control in distributed transaction

3. Introduction
• Each server manages a set of objects and is
responsible for ensuring that they remain
consistent when accessed by concurrent
transaction.
• Therefore ,each server is responsible for
applying concurrency control to its own
objects.

4. Concurrency control in distributed
Including
transaction
1. Locking
2. Timestamp ordering concurrency control
3. Optimistic concurrency control

5. 1. Locking
• In a distributed transaction, the locks on an
objects are held locally( in the same server).
• The lock manager can decide whether to grant
a lock or make the requesting transaction
wait.

6. • It cannot release any locks until it knows
that the transaction has been committed
or aborted at all the servers involved in the
transaction.

7. • Consider the following interleaving of
transactions T and U at servers X and Y.

8. Example of a distributed deadlock
T U
Write(A) At X Locks A
Read(B) At Y Wait for U
Write(B) At Y Locks B
Read(A) At X Wait for T

9. • These different ordering can lead to cyclic
dependencies between transactions and a
distributed deadlock situation arises.
• When a deadlock is detected, a transaction is
aborted to resolve the deadlock.
• In this case, the coordinator will be informed
and will abort the transaction at the
participants involved in the transaction.

10. Distributed deadlock
D
Waits for
C A
Waits
for
Held by
Held
by
B Waits for
Held
by
X
Y
Z
Held by
W
V U
W
V
U
(a) (b)

11. 2. Timestamp ordering concurrency control
• Globally unique transaction timestamp
– Be issued to the client by the first coordinator
accessed by a transaction
– The transaction timestamp is passed to the
coordinator at each server
– Each server accesses shared objects
according to the timestamp
• Resolution of a conflict
– Abort a transaction from all servers

12. 3. Optimistic concurrency control
• Each transaction has the following phases
1. Working phase
2. Validation phase
3. Update phase

13. 1. Working phase
• During the working phase, each transaction has
a tentative (unsure) version of each of the
objects that it updates.
• This is a copy of the most recently committed
version of the object.
• When there are several concurrent transactions,
several different tentative values of the same
object may coexist.

14. 2. Validation phase
• When the closeTransaction request is
received, the transaction is validated to
establish whether or not its operations on
objects conflict with operations of other
transactions on the same objects.
• If the validation is successful, then the
transaction can commit.
• If the validation fails, then some form of
conflict resolution must be used and
either the current transaction will need to
be aborted.

15. Validation of transactions
For a transaction Tv to be serializable with respect
to an overlapping transaction Ti , their operation
must conform to the following rules.

16. Tv Ti Rule
write read Ti must not read objects written
by Tv
read write Tv must not read objects written
by Ti
write write Ti must not write objects written
by Tv and
Tv must not write objects written
by Ti

17. 3. Update phase
• If a transaction is validated, all of the
changes recorded in its tentative versions
are made permanent.
• Read-only transactions can commit
immediately after passing validation.
• Write transactions are ready to commit
once the tentative versions of the objects
have been recorded in permanent
storage.

18. Thank You