1. Introduction

2. Flat and nested distributed transactions

3. Atomic commit protocols

4. Concurrency control in distributed

transactions

5. Distributed deadlocks

6. Transaction recovery

Distributed Transactions

4. Concurrency control in distributed transaction

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.

Including

1. Locking

2. Timestamp ordering concurrency control

3. Optimistic concurrency control

Concurrency control in distributed

transaction

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.

• It cannot release any locks until it knows

that the transaction has been committed

or aborted at all the servers involved in the

transaction.

• Consider the following interleaving of

transactions T and U at servers X and Y.

Example of a distributed deadlock

T U

Write(A) Locks AAt X

Read(B) Wait for U At Y

Write(B) Locks BAt Y

Read(A) Wait for T At X

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

Distributed deadlock

D

Waits for

Waits

for

Held by

Held

by

B Waits for

Held

by

X

Y

Z

Held by

W

UV

AC

W

V

U

(a) (b)

• 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

2. Timestamp ordering concurrency control

3. Optimistic concurrency control

• Each transaction has the following phases

1. Working phase

2. Validation phase

3. Update phase

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.

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.

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.

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

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.

Thank You