Slide 1

Chapter 3
Concurrency Control Techniques
• Purpose of Concurrency Control
▫ To ensure Isolation property of concurrently
executing transactions
▫ To preserve database consistency
▫ To resolve read-write and write-write conflicts
• Example:
▫ In concurrent execution environment,
 if T1 conflicts with T2 over a data item A, then
the existing concurrency controller decides if T1
or T2 should get A and which transaction should
be rolled-back or waits
 Slide 2

Concurrency Control (cont…)

1. Concurrency control using Locks

▫ A lock is a mechanism to control concurrent access
to a data item
• Locking is an operation which secures
 (a) permission to Read
 (b) permission to Write a data item for a
transaction.
▫ Notation :
:Li(X) –Transaction Ti requests a lock on
database element X
▫ Unlocking is an operation which removes these
permissions from the data item.
▫ Notation :
 Ui (X): Transaction Ti releases (“unlocks”) its
lock on database element X
▫ Lock and Unlock are Atomic operations.
 Slide 3

Concurrency Control (cont…)

Types of locks and system lock tables

• Binary locks
▫ Can have two states or values: locked and unlocked(0
or 1)
▫ A distinct lock is associated with each database item X
▫ If the value of the lock on X is 1, item X can not be
accessed by a database operation that request the
item
▫ Too restrictive for database items because at most
one transaction can hold a lock on a given item
• Shared/Exclusive (or read /write) locks
▫ Allow several transactions to access the same item x if
they all access x for reading purposes
 Slide 4

Database Concurrency Control

• In shared/exclusive method, data items

can be locked in two modes :
▫ Shared mode: shared 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
 Slide 5
Concurrency Control (cont…)

• When we use the shared/exclusive locking

scheme, the system must enforce the following
rules:
1. A transaction must issue the operation
read_lock(x) or write_lock(x) before any
read_item (x) operation is performed in T
2. A transaction T must issue the operation
write_lock(x) before any write_item (x) operation
is performed in T
3. A transaction T must issue the operation
unlock_lock(x) after all read_item(x) and
write_item (x) operation are completed in T
4. A transaction will not issue a read_lock(x)
operation if it already holds a read(shared) lock
or a write (exclusive) lock on item X
5. A transaction will not issue a write_lock(x)
operation if it already holds read(shared) lock or
write(exclusive) lock on item x
6. A transaction T will not issue an unlock(x)
operation unless it already holds a read(shared)
lock or a write(exclusive) lock on item x
 Slide 6

Concurrency Control (cont…)

Lock conversion
• Sometimes, it is desirable to relax condition 4 and 5 in
the coding list in order to allow lock conversions. That is
:
▫ Under certain conditions, a transaction that already
holds a lock on item X is allowed to convert the lock
from one lock state to another.
▫ For example, it is possible for a transaction T to issue
a read_lock (X) and then later on to upgrade the lock
by issuing a write_lock(x) operation
▫ If T is the only transaction holding a read lock on x at
the time it issues the write_lock (x) operation, the lock
can be upgraded ;otherwise, the transaction must
wait.
▫ It is also possible for a transaction T to issue a
write_lock(X) and then later on to downgrade the lock
by issuing a read_lock(X) operation
 Slide 7

Concurrency Control (cont…)

▫ Lock upgrade: change 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: change existing write lock
to read lock
If Ti has a write-lock (X) (*no transaction can
have any lock on X*)
convert write-lock (X) to read-lock (X)
 Slide 8

Database Concurrency Control (cont…)

• Lock compatibility
▫ A transaction may be granted a lock on an item if the
requested lock is compatible with locks already held
on the item by other transactions
▫ Any number of transactions can hold shared locks on
an item,
 But if any transaction holds an exclusive lock on the item
no other transaction may hold any lock on the item.
▫ If a lock cannot be granted, the requesting
transaction will be made to wait untill all
incompatible locks held by other transactions have
been released
 Lock compatibility matrix
 Slide 9

Concurrency Control (cont…)

• The DBMS has lock manager subsystem to

control locks
▫ Lock Manager:
 Manages locks on data items.
▫ Lock table:
 Lock manager uses it to store the identify of
transaction that lock the data item
 Slide
10

Lock Table • Black rectangles indicate

granted locks, white ones
indicate waiting requests
• Lock table also records the
type of lock granted or
requested
• New request is added to the
end of the queue of requests
for the data item, and
granted if it is compatible
with all earlier locks
• Unlock requests result in the
request being deleted, and
Granted later requests are checked to
Waiting see if they can now be
granted
• If transaction aborts, all
waiting or granted requests
of the transaction are deleted
 Slide
11

Concurrency Control (cont…)

Using binary or read write locks in transactions as described earlier
by itself
does not guarantee serializability :

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

Concurrency Control (cont…)

T1 T2 Result

read_lock (Y); X=50; Y=50

read_item (Y); Nonserializable because it
unlock (Y); violated two-phase policy.
read_lock (X);
read_item (X);
Time unlock (X);
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);
 Slide
13

Guaranteeing serializability by Two-Phase

Locking Protocol (2 PL)
• A transaction is said to follow two phase locking protocol
if all locking operations (either read_lock or write_lock)
precede the first unlock operation in the transaction
• This is a protocol which ensures conflict-serializable
schedules.
▫ Phase 1: Growing Phase
 transaction may obtain locks
 transaction may not release locks
▫ Phase 2: Shrinking Phase
 transaction may release locks
 transaction may not obtain locks
• It can be proved that the transactions can be serialized in
the order of their lock points (i.e. the point where a
transaction acquired its final lock).
 Slide
14

Database Concurrency Control

T’1 T’2
read_lock (Y); read_lock (X); T’1 and T’2 follow two-
phase
read_item (Y);read_item (X); policy but they are
subject to
write_lock (X); Write_lock (Y); deadlock
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);
 Slide
15

Database Concurrency Control

• Two-phase locking policy generates two locking
algorithms
▫ (a) Basic
▫ (b) Conservative
▫ Basic:
 Transaction locks data items incrementally. This
may cause deadlock
▫ Conservative:
 Prevents deadlock by locking all desired data
items before transaction begins execution.
 Slide
16

Dealing with Deadlock and Starvation

Deadlock :occurs when each transaction T in a set of
two or more transactions is waiting for an item that
is locked by some other transaction T’ in the set

Example of deadlock situation:

T’1 T’2
read_lock (Y); T’1 and T’2 enter
deadlock
read_item (Y);
read_lock (X);
read_item (X);
write_lock (X);
(waits for X) write_lock (Y);
(waits for Y)
 Slide
17

Dealing with Deadlock and Starvation

T1 T2
read_lock (Y);
read_item (Y);
unlock (y)
read_lock (X);
read_item (X);
unlock (X)

write_lock (X);
write_lock (Y);

• There is no deadlock in this schedule since T1

unlocks y and T2 unlocks x
 Slide
18

Deadlock and Starvation (cont…)

• Deadlock prevention
1. A transaction locks all the needed data items
before it begins execution
 This way of locking prevents deadlock since a
transaction never waits for a data item
 If any of the items cannot be obtained, none
of the items are locked. Rather the
transaction tries again to lock all the items it
needs
 This solution limits concurrency and generally
not a practical assumption
 Slide
19

Deadlock and Starvation (cont…)

2. Making a decision about what to do with a
transaction involved in a possible deadlock
situation:
▫ Should it be blocked and made it to wait or should
it be aborted
▫ Should the transaction preempt and abort another
transaction
• These concepts use transaction timestamp TS(T)
which is a unique identifier assigned to each
transaction based on the order they started
• If transaction T1 starts before transaction T2, then
TS (T1) < TS(T2)
 Slide
20

Deadlock and Starvation (cont…)

• Deadlock prevention
▫ Two schemes that prevent dead lock based on time
stamp includes wait –die and wound-wait
▫ Suppose that transaction Ti 100 tries to lock an item
X but is not able to do so because X is locked by some
other transaction Tj 90 with a conflicting lock. The
rules followed by these two schemes are as follows:
 Wait – die: If TS(Ti) < TS(Tj) i.e Ti is older than Tj, then
Ti is allowed to wait ; other wise, abort Ti (Ti dies) and
restart it later with the same time stamp
 Wound - wait: If TS(Ti) < TS(Tj), abort Tj (Ti wounds Tj)
and restart it later with the same timestamp; other wise
Ti is allowed to wait.
 Slide
21

Deadlock and Starvation (cont…)

• Another group of protocols that prevent
deadlock do not require timestamps
 No waiting (NW) – If transaction is unable to
obtain lock, it will be immediately aborted and
restarted after some time delay
 This method cause transactions to abort and restart
transactions needlessly
 Cautious waiting (CW) – Suppose that transaction
Ti tries to lock an item X but is not able to do so because
X is locked by some other transaction Tj with a conflicting
lock; the cautious rule suggest that :
 If Tj is not blocked (not waiting for some other locked
item), then Ti is blocked and allowed to wait; otherwise
abort Ti
 Slide
22

Deadlock and Starvation (cont…)

• Starvation
▫ Starvation occurs when a particular transaction
consistently waits or restarted and never gets a
chance to proceed further
▫ solution for starvation is to have a fair waiting
scheme, such as using a first-come-first-
served queue.
▫ In a deadlock resolution, it may be possible that the
same transaction may consistently be selected as
victim and rolled-back
▫ 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
 Slide
23

2. Concurrency control based on Timestamp

ordering

• Timestamp (TS)
▫ Timestamp is a unique identifier created by the
DBMS to identify 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
▫ Timestamp ordering algorithm associates two
timestamp values (TS) with each database item X
1. Read_TS(x) : the read timestamp of 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
 Slide
24

Timestamp ordering (cont…)

2. Write_TS(X) : This is the largest of all the

timestamps of transactions that have
successfully written item x – that is, write_TS(x)
= TS(T), where T is the youngest transaction
that has written x successfully
• Basic Timestamp Ordering (TO):
▫ whenever some transaction T tries to issue a
read_item(X) or a write_item(X) operation, the
basic TO algorithm compares the timestamp of T
with read_TS(X) and write_TS(X)
• The concurrency control algorithm must check
whether conflicting operations violate the
timestamp ordering as in the two cases provided in
the next slide:
 Slide
25

Timestamp ordering (cont…)

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

a) If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then a
younger transaction has already read or written the
data item so abort and roll-back T and reject the
operation.
This is because a younger transaction has already read
or written the value before T had the chance to write X;
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:
a) If write_TS(X) > TS(T), then abort and roll-back T and
reject the operation. This is because a younger
transaction has already written the value before T had
the chance to read X;
b) 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)
 Slide
26

3. 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.
▫ Unlike other mechanisms a read operation
in this mechanism is never rejected
▫ Side effect:
 Need 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
 Slide
27

Multiversion techniques
(cont…)
• Assume X1, X2, …, Xn are the version of a
data item X created by a write operation of
transactions.
 With each Xi a read_TS (read timestamp) and a
write_TS (write timestamp) are associated.
▫ read_TS(Xi): The read timestamp of Xi is
the largest of all the timestamps of
transactions that have successfully read
version Xi.
▫ write_TS(Xi): The write timestamp of Xi
that wrote the value of version Xi.
 Slide
28

Multiversion techniques
(cont…)
▫ Whenever a transaction T is allowed to
execute a write_item(X) operation, a new
version Xk+1 of item X is created with both
the write_TS(Xk+1) and read_TS(Xk+1) set to
TS(T).
▫ Correspondingly, when a transaction is
allowed to read the value of xi, the value of
read_TS(xi) is set to the larger of the
current read_TS(xi) and TS(T)
 Slide
29

Multiversion techniques (cont…)

• To ensure serializability, the following two rules are
used.
1) If transaction T issues write_item (X) and version i of
X has the highest write_TS(Xi) of all versions of X that
is also less than or equal to TS(T), and read _TS(Xi) >
TS(T), then abort and roll-back T; otherwise create a
new version Xj of X with read_TS(Xj) = write_TS(Xj)
= TS(T)
2) If transaction T issues read_item (X), find the
version i of X that has the highest write_TS(Xi) of all
versions of X that is also less than or equal to TS(T),
then return the value of Xi to transaction T, and set
the value of read _TS(Xi) to the largest of TS(T) and
the current read_TS(Xi)
▫ Rule 2 guarantees that a read will never be rejected.
 Slide
30

4. Validation (Optimistic) Concurrency

Control Schemes
• In this technique, serializability is checked only at the
time of commit and transactions are aborted in case of
non-serializable schedules
• No checking is done while transaction is executing
• In this scheme, updates in the transaction are not applied
directly to the database item until it reaches its commit
point
• Three phases:
1. Read phase
2. Validation phase
3. Write phase
1. 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)
 Slide
31

4. Validation (Optimistic) Concurrency

Control Schemes
2. Validation phase: Serializability is
checked before transactions write their
updates to the database.
3. Write phase: On a successful validation
transactions’ updates are applied to the
database; otherwise, transactions are
restarted
 Slide
32

Granularity of data items and Multiple

Granularity Locking (MGL)
• A lockable unit of data defines its granularity.
• Granularity can be coarse (entire database) or it
can be fine (a tuple or an attribute of a relation).
• Data item granularity significantly affects
concurrency control performance.
• Thus, the degree of concurrency is low for coarse
granularity and high for fine granularity.
• Example of data item granularity:
1. A field of a database record (an attribute of a
tuple)
2. A database record (a tuple or a relation)
3. A database table
4. The entire database
 Slide
33

Granularity of data items and Multiple

Granularity Locking (Cont…)
• The following diagram illustrates a
DB from coarse to
hierarchy of granularity
fine
f1 f2

p11 p12 …… p1n p21 p22.......p2m

r111... r11j r12...r12j r1n1..r1nj r211... r21k r221 ... r21k r2m1 ... r2mk
 Slide
34

Granularity of data items and Multiple

Granularity Locking (Cont…)
• To make multiple granularity level locking practical,
three additional locking modes, called intention lock
modes are defined:
▫ Intention-shared (IS): indicates that a shared lock(s)
will be requested on some descendent nodes(s).
▫ Intention-exclusive (IX): indicates that an exclusive
lock(s) will be requested on some descendent node(s).
▫ Shared-intention-exclusive (SIX): indicates that the
current node is locked in shared mode but an exclusive
lock(s) will be requested on some descendent nodes(s)
• The idea behind intention locks is for a transaction
to indicate what type of lock (shared or exclusive) it
will require from one of the node’s descendants
 Slide
35

Granularity of data items and Multiple

Granularity Locking (Cont…)
• Intention locks are applied using the
following compatibility matrix:

Intention-shared (IS)
Intention-exclusive (IX)
IS IX S SIX X Shared-intention-exclusive (SIX)
IS yes yes yes yes no
IX yes yes no no no
S yes no yes no no
SIX yes no no no no
X no no no no no
 Slide
36

(Cont…)
• The set of rules (multiple granularity locking, MGL)
which must be followed for producing serializable
schedule are:
1. The lock compatibility must adhered to.
2. The root of the tree must be locked first, in any
mode..
3. A node N can be locked by a transaction T in S
or IX mode only if the parent node is already
locked by T in either IS or IX mode.
4. A node N can be locked by T in X, IX, or SIX
mode only if the parent of N is already locked by
T in either IX or SIX mode.
5. T can lock a node only if it has not unlocked any
node (to enforce 2PL policy).
6. T can unlock a node, N, only if none of the
children of N are currently locked by T.
 Slide
37

Granularity of data items and Multiple

Granularity Locking (Cont…)
• Rule 1 simply states that conflicting locks can not
be granted
• Rules 2,3 and 4 state the conditions when a
transaction may lock a given node in any of the
lock modes
• Rules 5 and 6 of the MGL protocol enforce 2PL
rules to produce serializable schedules.
• For illustration of MGL protocol with the database
hierarchy shown on slide 33, consider the
following three conditions:
▫ T1 wants to update record r111 and record r211
▫ T2 wants to update all records on page p12
▫ T3 wants to read record r11j and the entire f2 file
 Slide
38

Granularity of data items and Multiple

Granularity Locking (Cont…)
Granularity of data items and Multiple Granularity Locking: An example of a
serializable execution:
T1 T2 T3
IX(db)
IX(f1)
IX(db)
IS(db)
IS(f1)
IS(p11)
IX(p11)
X(r111)
IX(f1)
X(p12)
S(r11j)
IX(f2)
IX(p21)
IX(r211)
Unlock (r211)
Unlock (p21)
Unlock (f2)
S(f2)
Continued to the next slide
 Slide
39

Cont…

• Granularity of data items and Multiple Granularity Locking:

An example of a serializable execution (continued):
T1 T2 T3
unlock(p12)
unlock(f1)
unlock(db)

unlock(r111)
unlock(p11)
unlock(f1)
unlock(db)
unlock (r111j)
unlock (p11)
unlock (f1)
unlock(f2)
unlock(db)
 Slide
40

Cont…

• Lock granularity affects concurrency in the

following manner:
▫ The larger the lock granularity used, the more
concurrency is reduced.
▫ This means that row-level locking maximizes
concurrency because it leaves all but one row on
the page unlocked.
▫ On the other hand, system overhead is increased
because each locked row requires one lock.
▫ Page level locking (and table-level locking)
restricts the availability of data but decreases
the system overhead.