s t e m

nt Sy
e m e
n a g
M a S)
b a s e B M
a t a e d D
e d D a n c 1 )
a nc A d v c 3 0 7
Ad v ( e
(I T
 Chapter Four

Concurrency Controlling Techniques

 Chapter Outline

Databases Concurrency Control

1. Purpose of Concurrency Control
2. Concurrency Control Techniques
2.1 Locking
2.2 Timestamp
2.3 Optimistic
2.4 Multiversion
Database Concurrency Control
• Transaction Processor is divided into:
 A concurrency-control manager, or scheduler, responsible for assuring
isolation of transactions
 A logging and recovery manager, responsible for the durability of
transactions.
• The scheduler (concurrency-control manager) must assure that the individual
actions of multiple transactions are executed in such an order that the net
effect is the same as if the transactions had in fact executed one-at-a-time.
Requests from
transactions

Lock Scheduler
Table
Read and Writes

Buffers
1. Purpose of Concurrency Control
ↆ To enforce Isolation (through mutual exclusion) among
conflicting transactions.
ↆ To preserve database consistency through consistency
preserving execution of transactions.
ↆ To resolve read-write and write-write conflicts.
A typical scheduler does its work by maintaining locks on certain
pieces of the database. These locks prevent two transactions from
accessing the same piece of data at the same time.
Example:
 In concurrent execution environment if T1 conflicts with T2
over a data item A, then the existing concurrency control
decides if T1 or T2 should get the A and if the other
transaction is rolled-back or waits.
Example:

Bank database: 3 Accounts

A = 500
Account B = 500
Balances
C = 500

Property: A + B + C = 1500

Money does not leave the system

 Example :-
Transaction T2: Transfer
Transaction T1: Transfer
100 from A to C
100 from A to B

Read (A, t) Read (A, s)

t = t - 100 s = s - 100
Write (A, t) Write (A, s)
Read (B, t) Read (C, s)

t = t + 100 s = s + 100
Write (B, t) Write (C, s)
 Transaction T1 Transaction T2 A B C

500 500 500

Read (A, t)
t = t - 100
Read (A, s)
s = s - 100
Write (A, s) 400 500 500

Write (A, t) 400 500 500

Read (B, t)
t = t + 100
Write (B, t) 400 600 500

Read (C, s)
s = s + 100
Write (C, s) 400 600 600
Schedule
400 + 600 + 600 = 1600
 Transaction T1 Transaction T2 A B C

500 500 500

Read (A, t)
t = t - 100
Write (A, t) 400 500 500
Read (A, s)
s = s - 100
Write (A, s) 300 500 500
Read (B, t)
t = t + 100
Write (B, t) 300 600 500

Read (C, s)
s = s + 100
Alternative Write (C, s) 300 600 600
Schedule
300 + 600 + 600 = 1500
So What ?
2. Concurrency Control Techniques

Basic concurrency control techniques:

Locking,
Time stamping
Optimistic methods
The first two are conservative approaches: delay transactions in
case they conflict with other transactions.

Optimistic methods assume conflict is rare and only check for

conflicts at commit.
 2.1. Locking
 Lock is a variable associated with a data item that describes the status of the
data item with respect to the possible operations that can be applied to it.
 Generally, a transaction must claim a shared (read) or exclusive (write) lock
on a data item before read or write.
 Lock prevents another transaction from modifying item or even reading it, in
the case of a write lock.
Locking is an operation which secures
 (a) permission to Read
 (b) permission to Write a data item for a transaction.
Example:
Lock (X). Data item X is locked in behalf of the requesting transaction.
Unlocking is an operation which removes these permissions from the data
item.
Example:
Unlock (X): Data item X is made available to all other transactions.
– Lock and Unlock are Atomic operations.
Two locks modes:
(a) shared (read) (b) exclusive (write).
 Shared mode: read lock (X)
More than one transaction can apply share 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.
 Conflict matrix
Read Write
Read

Y N

N N
Write
Lock Manager:
 Managing locks on data items.
Lock table:
 Lock manager uses it to store the identity of transaction
locking a data item, the data item, lock mode and pointer
to the next data item locked. One simple way to implement a
lock table is through linked list.

Transaction ID Data item id lock mode Ptr to next data item

T1 X1 Read Next

Database requires that all transactions should be well-formed. A

transaction is well-formed if:
 It must lock the data item before it reads or writes to it.
 It must not lock an already locked data items and it must
not try to unlock a free data item.
 Locking - Basic Rules
 It has two oprerations : Lock_item(X) and unLock_item(X)
 A transaction request access to an item X by first issuing a lock_Item(x)
opreation .
 If lock (X)=1, the transaction is forced to wait.
 If lock (X)= 0; it is set to 1 and the transaction is allowed to access x
 When a transaction finished operation on X it issues an Unlock _item operation
which set lock(x) to 0 so that X may be accessed by another transaction
 If transaction has shared lock on item, can read but not update item.
 If transaction has exclusive lock on item, can both read and update item.
 Reads cannot conflict, so more than one transaction can hold shared locks
simultaneously on same item.
 Exclusive lock gives transaction exclusive access to that item.
 The following code performs the read operation: 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;

The following code performs the write lock operation: write_lock(X):

B: if LOCK (X) = “unlocked” then
LOCK (X)  “write-locked”;
else
wait (until LOCK(X) = “unlocked”
and the lock manager wakes up the transaction);
goto B
end;
 Lock conversion
 Lock upgrade: existing read lock to write lock.
if Ti has a read-lock (X) and Tj has no read-lock (X) (i  j)
then
convert read-lock (X) to write-lock (X)
else
force Ti to wait until Tj unlocks X
 Lock downgrade: existing write lock to read lock
Ti has a write-lock (X) (*no transaction can have any lock on
X*) convert write-lock (X) to read-lock (X)
Using such locks in the transaction do not guarantee
serializability of schedule on its own: example
 Example : Incorrect Locking Schedule

T1 T2
Schedule: A Write Lock( X)
Read (X)
X=X+100
Write(X)
Unlock(X)
Write Lock( X)
Read (X)
X= X*1.1
Write(X)
Unlock(X)
Write
Lock( Y)
Read (Y)
Y= Y*1.1
Write(Y)
Unlock(Y)
Commit
Write Lock( Y)
Read(Y)
Y= Y-100
Write(Y)
Unlock(Y)
Commit
 Cont’d..

• If at start, X = 100, Y = 400, result should be:

X = 220, y = 330, if T1 executes before T2, or

X = 210, Y = 340, if T2 executes before T1
• However, result gives X= 220 and Y = 340.
• S is not a serializable schedule. Why?
Problem is that transactions release locks too soon,
resulting in loss of total isolation and atomicity.
To guarantee serializability, we need an additional protocol
concerning the positioning of lock and unlock operations in
every transaction.
2.1.1 Two-Phase Locking (2PL) Techniques: The algorithm

Transaction follows 2PL protocol if all locking operations precede

first unlock operation in the transaction.
Every transaction can be divided into Two Phases: Locking (Growing) &
Unlocking (Shrinking)
Locking (Growing) Phase:
• A transaction applies locks (read or write) on desired data items
one at a time.
• acquires all locks but cannot release any locks.
Unlocking (Shrinking) Phase:
• A transaction unlocks its locked data items one at a time.
• Releases locks but cannot acquire any new locks.
Requirement:
For a transaction these two phases must be mutually exclusively, that is,
during locking phase unlocking phase must not start and during unlocking
phase locking phase must not begin.

# locks
held by
Ti

Growing Phase Shrinking Phase Time 19

Example
T1 T2
Result
read_lock (Y); read_lock (X);
Initial values: X=20; Y=30
read_item (Y);read_item (X);
unlock (Y); unlock (X); Result of serial execution
write_lock (X); Write_lock (Y);T1 followed by T2
read_item (X);read_item (Y); X=50, Y=80.
X:=X+Y; Y:=X+Y; Result of serial execution
write_item (X); write_item (Y);
T2 followed by T1
unlock (X); unlock (Y);
X=70, Y=50
 T1 T2

read_lock (Y);

read_item (Y);
Result
unlock (Y); X=50; Y=50
Nonserializable because it
read_lock violated two-phase policy.
(X);
read_item
(X);
unlock
(X);
Time write_lock
(Y);
read_item
(Y);
Y:=X+Y;
write_item
(Y);
unlock
(Y);
write_lock (X);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);
T’1 T’2
read_lock (Y); read_lock (X);
read_item (Y);read_item (X); T’1 and T’2 follow two-phase
write_lock (X); Write_lock (Y); policy but they are subject to
deadlock, which must be dealt
unlock (Y); unlock (X); . with ;
read_item (X);read_item (Y); Refere :- page 784
X:=X+Y; Y:=X+Y;
write_item (X); write_item (Y);
unlock (X); unlock (Y);

If every transaction in the schedule follows the 2PL protocol , the

schedule is guaranteed to be serializabe
• Remark:
2PL protocol guarantees serialzability but it doesn’t permit all
the possible serializability schedule
The use of this locking can cause two additional problems

 Deadlock
 Starvation
Dealing with Deadlock and Starvation
• Deadlock
– It is a state that may result when two or more transaction are
each waiting for locks held by the other to be released
– Example :
T1 T2
read_lock (Y);
read_item (Y);
read_lock (X);
read_item (X);
write_lock (X);
write_lock (Y);

– T1 is in the waiting queue for X which is locked by T2

– T2 is on the waiting queue for Y which is locked by T1
– No transaction can continue until the other transaction
completes
– T1 and T2 did follow two-phase policy but they are deadlock
So the DBMS must either prevent or detect and resolve such
 There are possible solutions :
Deadlock prevention, deadlock detection and avoidance and lock timeouts
i. Deadlock prevention protocol: two possibilities
The conservative two-phase locking
A transaction locks all data items it refers to before it begins execution.
This way of locking prevents deadlock since a transaction never waits for a data item.
Limitation : It restrictions concurrency
Transaction Timestamp( TS(T) )
We can prevent deadlocks by giving each transaction a priority and ensuring that lower
priority transactions are not allowed to wait for higher priority transactions (or vice
versa ).
One way to assign priorities is to give each transaction a timestamp when it starts up.
it is a unique identifier given to each transaction based on time in which it is started.
i.e if T1 starts before T2 , TS(T1)<TS(T2)
The lower the timestamp, the higher the transaction's priority, that is, the oldest
transaction has the highest priority.
If a transaction Ti requests a lock and transaction Tj holds a conflicting lock, the
lock manager can use one of the following two policies: Wait-die & Wound-wait
• Wait-die
– If Ti has higher priority, it is allowed to wait; otherwise it is aborted.
– An older transaction is allowed to wait on a younger transaction.
– A younger transaction requesting an item held by an older transaction is
aborted
– If TS(Ti) < TS(Tj), then (Ti 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

T1(ts =10): M is locked , K is requested

wait wait

T2 (ts =20): K is locked, Z is requested

wait

T3 (ts =25) : Z is locked, M is requested

• Wound-wait
– The opposite of wait-die
– If Ti has higher priority, abort Tj; otherwise Ti waits.
– A younger transaction is allowed to wait on an older one
– An older transaction requesting an item held by a younger transaction
preempts the younger transaction by aborting it.
– If TS(Ti) < TS(Tj), then (Ti older than Tj),Abort Tj (Ti wounds Tj) and
restart Tj later with the same timestamp
– Otherwise (Ti younger than Tj)Ti is allowed to wait

T1(ts =25)

wait wait

T2 (ts =20)
wait

T3 (ts =10) 27
 Remark:
− Both methods ended by aborting the younger of the two transaction that
may be involved in the deadlock
− Limitation:
−Both techniques may cause some transaction to be aborted and
restarted unnecessarily
ii. Deadlock Detection and resolution
– In this approach, deadlocks are allowed to happen
– The scheduler maintains a wait-for-graph for detecting cycle.
– When a chain like: Ti waits for Tj waits for Tk waits for Ti or Tj occurs,
then this creates a cycle.
– When the system is in the state of deadlock , some of the transaction
should be aborted by selected (victim) and rolled-back
– This can be done by aborting those transaction: that have made the least
work, the one with the lowest locks, and that have the least # of abortion
and so on
Example:
iii.Timeouts
– It uses the period of time that several transaction have been
waiting to lock items
– It has lower overhead cost and it is simple
– If the transaction wait for a longer time than the predefined time
out period, the system assume that may be deadlocked and aborted
it
 Starvation
– Starvation occurs when a particular transaction consistently waits
or restarted and never gets a chance to proceed further while other
transaction continue normally
– This may occur , if the waiting method for item locking:
• Gave priority for some transaction over others
• Problem in Victim selection algorithm- it is possible that the same
transaction may consistently be selected as victim and rolled-
back .example In Wound-Wait
Solution :-
 FIFO
 Allow for transaction that wait for a longer time
 Give higher priority for transaction that have been aborted for
many time
 2. 2.Timestamp based concurrency control algorithm
ʘ Timestamp
– In lock based concurrency control , conflicting actions of different
transactions are ordered by the order in which locks are obtained.
– But here, Timestamp values are assigned based on time in which the
transaction are submitted to the system using the current date & time of the
system
– 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.
– Timestamp based algorithm uses timestamp to serialize the execution of
concurrent transactions.
– It doesn’t use lock, thus deadlock cannot be occurred
– In the timestamp ordering, conflicting operation in the schedule shouldn’t
violate serilazable ordering
– This can be achieved by associating timestamp value (TS) to each database
item which is denoted as follow:
a) Read_Ts(x): the read timestamp of x – this is the largest time among all the
time stamps of transaction that have successfully read item X
b) Write_TS(X): the largest of all the timestamps of transaction that have
successfully written item X
 The concurrency control algorithm check whether conflict operation violate
the timestamp ordering in the following manner: three options
i. Basic Timestamp Ordering
 Transaction T issues a write_item(X) operation:
•If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an younger
transaction has already read/write the values of the data item x before
T had a chance to write X . so abort and roll-back T and restarted
with a new, larger timestamp. Why is with new timestamp?, is there a difference
b/n this timestamp protocol and the 2PL for dead lock prevention?
•If the condition above does not exist, then execute write_item(X)
of T and set write_TS(X) to TS(T).
 Transaction T issues a read_item(X) operation:
•If write_TS(X) > TS(T), then a younger transaction has already
written to the data item,so abort and roll-back T and reject the
operation.
•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)
– Limitation: cyclic restart/starvation may occur when a transaction is
continuously aborted and restarted
ii. Strict Timestamp Ordering
1. Transaction T issues a write_item(X) operation:
• 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:
• If TS(T) > write_TS(X), then delay T until the transaction T’
that wrote X has terminated (committed or aborted).
iii. Thomas’s Write Rule : Modification of Basic Time ordering Algo
 A transaction T issue a write_Item(X) Operation:
1. If read_TS(X) > TS(T) then abort and roll-back T and reject the
operation.
2. If write_TS(X) > TS(T), then just ignore the write operation and
continue execution. This is because the most recent writes counts in
case of two consecutive writes. Example
3. If the conditions given in 1 and 2 above do not occur, then execute
write_item(X) of T and set write_TS(X) to TS(T).

B
A

The Thomas Write Rule relies on the observation that T2's write is never seen
by any transaction
 2.3 VALIDATION (OPTIMISTIC) CONCURRENCY CONTROL
TECHNIQUES
• 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.
For example, in locking, a check is done to determine whether the item being
accessed is locked.
• In timestamp ordering, the transaction timestamp is checked against the read
and write timestamps of the item.
• In optimistic concurrency control techniques, also known as validation or
certification techniques, no checking is done while the transaction is executing.
• In this scheme, updates in the transaction are not applied directly to the
database items until the transaction reaches its end.
• During transaction execution, all updates are applied to local copies of the data
items that are kept for the transaction.
 Cont’d...
There are three phases for this concurrency control protocol:
Read phase: A transaction can read values of committed data items from
the database. However, updates are applied only to local copies (versions)
of the data items kept in the transaction workspace.
Validation phase: Checking is performed to ensure that serializability will
not be violated if the transaction updates are applied to the database.
Write phase: If the validation phase is successful, the transaction updates
are applied to the data base; otherwise, the updates are discarded and the
transaction is restarted.
2. 4. 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.
 This algorithm uses the concept of view serilazabilty than conflict
serialiazabilty
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.
 GROUP ASSIGNMENT(20%)(Group 1,3,)(W2)
 Basic, Conservative, Strict, and Rigorous Two-Phase Locking.
 Granularity of Data Items and Multiple Granularity Locking
 Using Locks for Concurrency Control in Indexes
 Other Concurrency Control Issues
:- Insertion, Deletion, and Phantom Records
:- Interactive Transactions
:-Latches, When are latches used?
Discuss two multiversion techniques for concurrency control.
What is a certify lock?
What are the advantages and disadvantages of using certify locks?