Concurrency Control Techniques

Concurrency Control Protocols

Lock-Based Protocols
Timestamp-Based Protocols
Validation-Based Protocols
Multiple Granularity
Multiversion Schemes
Deadlock Handling
 Concept Of LOCK
• A lock is a variable associated with a data item
that describes the data item with respect to
possible operation that can be applied to it.
• A transaction places a LOCK on the resource it
requires to use.
• Types of Locks –
• Binary Locks
• Shared/Exclusive (Read / Write) Locks.
 Binary Locks
• A binary lock can have two states or values:
locked (1) or unlocked (0)
If the value of the lock on item X is 1, item X cannot be accessed by a
database operation that requests X.
If the value of the lock on item X is 0, item X can be accessed when
requested.
• The current value of the lock on item X is referred to as LOCK(X).
Binary locks are kept in a lock table which contains records where
each record contains three fields:
<DB Item, LOCK, Locking Transaction>
Only items that are locked are kept in the table. Items that are not in
the table are considered to be unlocked.

The DBMS has A Lock Manager Subsystem to keep track of and

control access to locks.
 Binary Lock Operation
The following code performs the lock operation:
lock-item(X):
B: if LOCK (X) = 0 (*item is unlocked*)
then LOCK (X)  1 (*lock the item*)
else begin
wait (until LOCK (X) = 0 and
the lock manager wakes up the
transaction);
goto B
end;
 Binary Lock Operation

The following code performs the unlock

operation:
unlock-item(X):
LOCK (X)  0 (*unlock the item*)
if any transactions are waiting then
wake up one of the waiting transactions;
 Rules for Binary Locking
To use the binary locking scheme, every transaction must obey the
following rules:
• A transaction T must issue the operation lock_item(X) before any
read_item(X) or write_item(X) operations are performed in T.

• A transaction T must issue the operation unlock_item(X) after all

read_item(X) or write_item(X) operations are completed in T.

• A transaction T will not issue a lock_item(X) operation if it already

holds the lock on item X.

• A transaction T will not issue a unlock_item(X) unless it already

holds the lock on item X.
Note - At most one transaction can hold the lock on a particular item.
Thus no two transactions can access the same item concurrently.
 Shared/Exclusive(or Read/Write) Locks
Two lock modes
– Shared (read) and
– Exclusive (write).
• Shared mode: shared lock (X). More than one transaction can
apply shared lock on X for reading its value but no write lock can be
applied on X by any other transaction.
• Exclusive mode: Write lock (X). Only one write lock on X can exist
at any time and no shared lock can be applied by any other
transaction on X.
Three locking operations –
– Read_lock(X)
– Write_lock(X)
– Unlock(X)
 Shared/Exclusive(or Read/Write) Locks

A lock associated with an item X , LOCK(X), now has

three possible states,
Read-locked
Write-locked
Unlocked
A read-locked item is also called shared-locked because
other transactions are allowed to read the item.
A write-locked item is called exclusive-locked because a
single transaction exclusively holds the lock on the
item.
 Shared/Exclusive Lock Operations
read_lock(X):
B: if LOCK (X) = “unlocked” then
begin LOCK (X)  “read-locked”;
no_of_reads (X)  1;
end
else if LOCK (X)  “read-locked” then
no_of_reads (X)  no_of_reads (X) +1
else begin wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the transaction);
go to B
end;
 Shared/Exclusive Lock Operations

write_lock(X):

B: if LOCK (X) = “unlocked” then

LOCK (X)  “write-locked”;
else begin
wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the transaction);
go to B
end;
 Shared/Exclusive Lock Operations
unlock(X):

if LOCK (X) = “write-locked” then

begin LOCK (X)  “unlocked”;
wakeup one of the transactions, if any
end
else if LOCK (X)  “read-locked” then
begin
no_of_reads (X)  no_of_reads (X) -1
if no_of_reads (X) = 0 then
begin
LOCK (X) = “unlocked”;
wakeup one of the transactions, if any
end
end;
 Rules for Shared/Exclusive Locking
To use the shared/Exclusive locking scheme, every transaction must obey
the following rules:
• A transaction T must issue the operation read_lock(X) or
write_lock(X) before any read_item(X) operation is performed in
T.
• A transaction T must issue the operation write_lock(X) before any
write_item(X) operation is performed in T.
• A transaction T must issue the operation unlock(X) after all
read_item(X) or write_item(X) operations are completed in T.
• A transaction T will not issue a read_lock(X) operation if it already
holds a read (shared) or a write (exclusive) lock on item X.
• A transaction T will not issue a write_lock(X) operation if it
already holds a read (shared) or a write (exclusive) lock on item
X.
• A transaction T will not issue a unlock_item(X) unless it already
holds a read (shared) or a write (exclusive) lock on item X.
 Lost Update Problem and Locking
T1 T2 T2's update to X is lost
read_lock(X ) because T1 wrote over X,
read_item ( X ) and it happened despite
unlock(X ) the fact that both
write_lock(X ) t
read_item X i transactions are issuing
X=X+M m lock and unlock commands
write_item(X ) e The problem is that T1
unlock(X ) releases lock on X so early,
allowing T2 to start
write_lock(X ) updating X
X=X–N
We need a protocol that
write_item (X )
unlock(X ) will guarantee
serializability
 The Two-Phase Locking Protocol
• It ensures serialisability.
• A transaction is said to follow the two-phase
locking protocol if all locking operations(read_lock,
write_lock) preceed the first unlock operation in the
transaction. Such a transaction can be divided into
two phases –
– Expanding or growing (first) phase – During which new
locks on items can be acquired but none can be released.
– Shrinking (second) phase – During which existing locks
can be released but no new locks can be acquired.
 T1 T2 Result
read_lock (Y); read_lock (X); Initial values: X=20; Y=30
Result of serial execution
read_item (Y); read_item (X); T1 followed by T2
unlock (Y); unlock (X); X=50, Y=80.
write_lock (X); Write_lock (Y);
Result of serial execution
read_item (X); read_item (Y); T2 followed by T1
X:=X+Y; Y:=X+Y; X=70, Y=50

write_item (X); write_item (Y);

unlock (X); unlock (Y);

T1 & T2 are transactions that do not obey two phase locking because the write_lock(X)
operation follows the unlock(Y) operation in T1, and the write_lock(Y) operation follows
the unlock(X) operaiton in T2.
 T1’ T2‘
read_lock (Y); read_lock (X);
read_item (Y); read_item (X); If we enforce two phase locking ,
write_lock (X); write_lock(Y) the transactions can be written
as T1’ & T2’
unlock (Y); unlock (X);
read_item (X); read_item (Y);
X:=X+Y; Y:=X+Y;
write_item (X); write_item (Y);
unlock (X); unlock (Y);

• Both T1’ and T2’ follow the 2PL protocol

• Any schedule including T1’ and T2’ is guaranteed to be serializable
• Limits the amount of concurrency
 Variations to 2PL Protocol
1. Basic - Previous technique is known as basic 2PL
2. Conservative 2 PL(or Static 2 PL) - Lock all items needed BEFORE
execution begins by pre-declaring its read and write set
Read-Set – of a transaction is the set of all items that the
transaction reads.
Write-set – of a transaction is the set of all items that it writes.
If any of the pre-declared items needed cannot be locked, the
transaction does not lock any item; instead it waits until all the
items are available for locking.
Conservative 2PL is a deadlock-free protocol
It is difficult to implement because of the need to pre-declare the
read-set and write-set, which is not possible in most situations.
 Variations to 2PLProtocol
3. Strict 2PL – A transaction T does not release its write
locks until AFTER it aborts/commits.
• Hence no other transactions can read or write an item
that is written by T unless T has committed, leading to a
strict schedule for recoverability.
• Most popular variation of 2PL
• Not deadlock free
• Note – Strict Schedule - Transaction can neither
read/write X until last transaction that wrote X has
committed/aborted.
 Variations to 2PLProtocol

4. Rigorous 2PL – A transaction T does not

release any of its locks(Exclusive or Shared)
until after it commits or aborts.
• It guarantees for a strict schedule.
• It is easier to implement than strict 2PL.
 Concluding Remarks

• Concurrency control subsystem is responsible for

inserting locks at right places into your
transaction
– Strict 2PL is widely used
– Requires use of waiting queue
• All 2PL locking protocols guarantee serializability.
 Problems with Locks

In some situations the use of locks can cause

two additional problems
– Deadlock
– Starvation
 Dealing with Deadlock
• Deadlock occurs when each transaction T in a
set of two or more transactions is waiting for
some item that is locked by some other
transaction T’ in the set.
• Hence each transaction in the set is on a
waiting queue, waiting for one of the other
transactions in the set to release the lock on
an item.
• Example next slide
Dealing with Deadlocks and Starvation in 2PL
 Deadlock Prevention Protocols
Deadlock prevention protocols ensure that the system will never
enter into a deadlock state. Some prevention strategies :

1. Require that each transaction locks all its data items before it
begins execution (pre-declaration).
This way of locking prevents deadlock since a transaction never
waits for a data item. The conservative two-phase locking uses
this approach.
2. Impose partial ordering of all data items and require that a
transaction can lock data items only in the order specified by the
partial order

Both are impractical for Databases!

 Deadlock Prevention

Other deadlock prevention algorithms use the concept of a

timsestamp TS(T) which is a unique identifier assigned to
transactions based on the order in which they start.

If T1 starts before T2, then

TS(T1) < TS(T2) (older transaction has the smaller

timestamp value)
 Deadlock Prevention
Examples of such algorithms are:

Wait-die: If TS(Ti) < TS(Tj), then (Ti is older than Tj) Ti is

allowed to wait; otherwise (Ti younger than Tj) abort Ti (Ti
dies) and restart it later with the same timestamp.

Wound-wait: If TS(Ti) < TS(Tj), then (Ti is older than Tj)

abort Tj (Ti wounds Tj) and restart it later with the same
timestamp; otherwise (Ti younger than Tj) Tj is allowed to
wait.
 Deadlock Prevention

•Both schemes end up with aborting with the younger

of the two transactions that may be involved in a
dedalock.
•In both the schemes there will be no cycles, so the
techniques are deadlock free.
•However, both techniques may cause some
transactions to be aborted and restarted needlessly,
even though those transactions may never actually
cause a deadlock.
 Deadlock Prevention
No Waiting Algorithm – In this technique if a transaction is
unable to obtain a lock, it is immediately aborted and restarted
after a certain time without checking whether a deadlock will
actually occur or not.
Problem – Because this scheme can cause transactions to
abort and restart needlessly.

To get rid of this problem a new algorithm was proposed.

Cautious Waiting Algorithm – If Tj is not blocked(not waiting

for some other locked item) , then Ti is blocked and allowed to
wait; otherwise abort Ti.
 Deadlock Detection
Deadlock Detection – Is an approach where a system checks if
a state of deadlock actually exists.
This approach is best when
The transactions are short and
Each transactions locks only a few items or
If the transaction load is not quite heavy.
On the other hand, if the transactions are long and each
transaction uses many items, or if the transaction load is quite
heavy, it may be advantageous to use a deadlock prevention
scheme.
A simple way to detect a deadlock is for the system to construct
& maintain a wait-for graph.
 Deadlock Detection
Wait-for graph –
• One node is created in the wait-for graph for each transaction
that is currently executing.
• When a transaction Ti is waiting to lock an item X that is
currently locked by a transaction Tj, a directed edge
(Ti Tj) is created in the wait-for graph.
We have a state of deadlock if and only if the wait-for graph has
a cycle.
The problem is of determining when the system should check for a
deadlock.
• Criteria such as number of currently executing transactions or
• The period of time several transactions have been waiting to
lock items to be used.
Dealing with Deadlocks and Starvation in 2PL
 Deadlock Recovery

• When deadlock is detected :

– Some transaction will have to rolled back (made a victim)
to break deadlock. Select that transaction as victim that
will incur minimum cost.
– Choosing which transactions to abort is known as victim
selection
– The algorithm for victim selection should generally avoid
selecting transactions that have been running for a long
time and that have performed many updates, and it
should try instead to select transactions that have not
made many changes.
 Starvation Problem
• Starvation occurs when a particular transaction
consistently waits or restarted and never gets a chance
to proceed further.
• In a deadlock resolution it is possible that the same
transaction may consistently be selected as victim and
aborted.
• This limitation is inherent in all priority based scheduling
mechanisms.
• In Wound-Wait scheme a younger transaction may
always be wounded (aborted) by a long running older
transaction which may create starvation.
Concurrency Control Based on Timestamp Ordering
•Timestamp is a unique identifier created by DBMS to identify a
transaction. A monotonically increasing variable (integer) indicating
the age of an operation or a transaction. A larger timestamp value
indicates a more recent event or operation.

Each transaction is issued a timestamp when it enters the system.

If an old transaction Ti has timestamp TS(Ti), a new transaction
Tk is assigned timestamp TS(Tk) such that TS(Ti) < TS(Tk).

•A timestamp can be thought of as the transaction start time.

•Timestamp based algorithm uses timestamp to serialize the

execution of concurrent transactions.
 Timestamp Ordering (TO) Algorithm
• The algorithm must ensure that, for each item accessed by
conflicting operations in the schedule, the order in which the
item is accessed does not violate the serializability order.
• Each database item X has two timestamp (TS) values:
– Read_TS(X): the read timestamp of item X; this is the
largest timestamp among all the timestamps of
transactions that have successfully read item X; read_TS(X)
= TS(T), where T is the youngest transaction that has read
X successfully.

– Write_TS(X): the write timestamp of item X; this is the

largest timestamp among all the timestamps of
transactions that have successfully written item X;
write_TS(X) = TS(T), where T is the youngest transaction
that has written X successfully.
 Basic Timestamp Ordering

Whenever some transaction T tries to issue a

read_item(X) or write_item(X) operation, the basic
TO algorithm compares the timestamp of T with
read_TS(X) and write_TS(X) to ensure that the
timestamp order of transaction execution is not
violated.
 Basic Timestamp Ordering
Two cases to check:
1. Transaction T issues a write_item(X) operation:
a. If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an
younger transaction has already read the data item so
abort and roll-back T and reject the operation.
b. If the condition in part (a) does not exist, then execute
write_item(X) of T and set write_TS(X) to TS(T).
2. Transaction T issues a read_item(X) operation:
c. If write_TS(X) > TS(T), then an younger transaction has
already written to the data item so abort and roll-back T
and reject the operation.
d. If write_TS(X)  TS(T), then execute read_item(X) of T
and set read_TS(X) to the larger of TS(T) and the current
read_TS(X).
• Basic TO Algorithm may cause the cascading
rollback
• If T is aborted and rollback, any transaction T1
that may have used a value written by T must
also be rollback. Similarly, any transaction T2
that may have used a value written by T1 must
also be rollback, and so on.
 Strict Timestamp Ordering

1. Transaction T issues a write_item(X) Operation:

a. If TS(T) > read_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).
2. Transaction T issues a read_item(X) operation:
b. If TS(T) > write_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).
Validation (Optimistic) Concurrency Control Schemes
In all the concurrency control techniques we have discussed
so far, a certain degree of checking is done before a
database operation can be executed like
1. In locking, a check is done to determine whether the item
being accessed is locked.
2. In timestamp ordering the transaction timestamp is
checked against the read and write timestamps of the
item.
Such checking represents overhead during transaction
execution, with the effect of slowing down the transactions
Validation (Optimistic) Concurrency Control Schemes

• In this technique only at the time of commit,

serializability is checked and transactions are
aborted in case of non-serializable schedules.
• There are three phases for this concurrency
control protocol:
1. Read phase
2. Validation phase
3. Write phase
Validation (Optimistic) Concurrency Control Schemes

• Read Phase - A transaction can read values of

committed data items. However, updates are applied
only to local copies (versions) of the data items
(in database cache).
• Validation phase: Serializability is checked before
transactions write their updates to the database.
• Write phase: On a successful validation transactions’
updates are applied to the database; otherwise, the
updates are discarded and the transaction is restarted.
 Multiversion concurrency control techniques
• This approach maintains a number of versions of a
data item and allocates the right version to a read
operation of a transaction. Thus, unlike other
mechanisms a read operation in this mechanism is
never rejected.
• Side effect:
• Significantly more storage (RAM and disk) is required
to maintain multiple versions. To check unlimited
growth of versions, a garbage collection is run when
some criteria is satisfied.
Multiversion technique based on timestamp ordering

• In this method several versions X1, X2, …, Xn of each

data item X are maintained. For each version, the
value of version xi and the following two timestamps
are kept.
1. read_TS(Xi) - The read timestamp of Xi is the largest of all
the timestamps of transactions that have successfully read
version Xi.
2. write_TS(Xi) - The write timestamp of Xi that wrote the value
of version Xi.
• A new version of Xi is created only by a write
operation.