Chapter 15 : Concurrency Control

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Lock-Based Protocols
 A lock is a mechanism to control concurrent access to a data
item
 Data items can be locked in two modes :
1. exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2. shared (S) mode. Data item can only be read. S-lock is

requested using lock-S instruction.

 Lock requests are made to the concurrency-control manager
by the programmer. Transaction can proceed only after
request is granted.

Database System Concepts - 6th Edition 15.2 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)
 Lock-compatibility matrix

 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 on the item no other
transaction may hold any lock on the item.
 If a lock cannot be granted, the requesting transaction is made to
wait till all incompatible locks held by other transactions have
been released. The lock is then granted.

Database System Concepts - 6th Edition 15.3 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)
 Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
 Locking as above is not sufficient to guarantee serializability
— if A and B get updated in-between the read of A and B,
the displayed sum would be wrong.
 A locking protocol is a set of rules followed by all
transactions while requesting and releasing locks. Locking
protocols restrict the set of possible schedules.

Database System Concepts - 6th Edition 15.4 ©Silberschatz, Korth and Sudarshan
 Lock Hierarchy
High Database • Generally, always has Shared Lock (S)
• Prevent database drop or restore

Table

Page

Low Row

19

Lock Working
Supposed we are going to read a record
from table

Database Shared Lock (S)

Table Intent Shared Lock (IS)

Page Intent Shared Lock (IS)

Row Shared Lock (S)

20

Database System Concepts - 6th Edition 15.5 ©Silberschatz, Korth and Sudarshan
 Lock Working
And if you are going to modify a
record

Database S
Table Intent X or Intent U

Page Intent X or Intent U

Row X or U
21

Lock Working
Locks shift from lower to higher level or vise versa

Table

Moves up when there 5,000 locks at any level

Page

Row
22

Database System Concepts - 6th Edition 15.6 ©Silberschatz, Korth and Sudarshan
Database System Concepts - 6th Edition 15.7 ©Silberschatz, Korth and Sudarshan
 The Two-Phase Locking Protocol

 This protocol 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
 The protocol assures serializability. 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).

Database System Concepts - 6th Edition 15.8 ©Silberschatz, Korth and Sudarshan
 The Two-Phase Locking Protocol (Cont.)

 There can be conflict serializable schedules that cannot be

obtained if two-phase locking is used.
 However, in the absence of extra information (e.g., ordering of
access to data), two-phase locking is needed for conflict
serializability in the following sense:
 Given a transaction Ti that does not follow two-phase
locking, we can find a transaction Tj that uses two-phase
locking, and a schedule for Ti and Tj that is not conflict
serializable.

Database System Concepts - 6th Edition 15.9 ©Silberschatz, Korth and Sudarshan
 Lock Conversions
 Two-phase locking with lock conversions:
– First Phase:
 can acquire a lock-S on item
 can acquire a lock-X on item
 can convert a lock-S to a lock-X (upgrade)
– Second Phase:
 can release a lock-S
 can release a lock-X
 can convert a lock-X to a lock-S (downgrade)
 This protocol assures serializability. But still relies on the
programmer to insert the various locking instructions.

Database System Concepts - 6th Edition 15.10 ©Silberschatz, Korth and Sudarshan
 Automatic Acquisition of Locks
 A transaction Ti issues the standard read/write instruction,
without explicit locking calls.
 The operation read(D) is processed as:
if Ti has a lock on D
then
read(D)
else begin
if necessary wait until no other
transaction has a lock-X on D
grant Ti a lock-S on D;
read(D)
end

Database System Concepts - 6th Edition 15.11 ©Silberschatz, Korth and Sudarshan
 Automatic Acquisition of Locks (Cont.)
 write(D) is processed as:
if Ti has a lock-X on D
then
write(D)
else begin
if necessary wait until no other transaction has any lock on D,
if Ti has a lock-S on D
then
upgrade lock on D to lock-X
else
grant Ti a lock-X on D
write(D)
end;
 All locks are released after commit or abort

Database System Concepts - 6th Edition 15.12 ©Silberschatz, Korth and Sudarshan
 Deadlocks
 Consider the partial schedule

 Neither T3 nor T4 can make progress — executing lock-S(B) causes

T4 to wait for T3 to release its lock on B, while executing lock-X(A)
causes T3 to wait for T4 to release its lock on A.
 Such a situation is called a deadlock.
 To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.

Database System Concepts - 6th Edition 15.13 ©Silberschatz, Korth and Sudarshan
 Deadlocks (Cont.)

 Two-phase locking does not ensure freedom from deadlocks.

 In addition to deadlocks, there is a possibility of starvation.
 Starvation occurs if the concurrency control manager is badly
designed. For example:
 A transaction may be waiting for an X-lock on an item,
while a sequence of other transactions request and are
granted an S-lock on the same item.
 The same transaction is repeatedly rolled back due to
deadlocks.
 Concurrency control manager can be designed to prevent
starvation.

Database System Concepts - 6th Edition 15.14 ©Silberschatz, Korth and Sudarshan
 Deadlocks (Cont.)
 The potential for deadlock exists in most locking protocols.
Deadlocks are a necessary evil.
 When a deadlock occurs there is a possibility of cascading roll-
backs.
 Cascading roll-back is possible under two-phase locking. To
avoid this, follow a modified protocol called strict two-phase
locking -- a transaction must hold all its exclusive locks till it
commits/aborts.
 Rigorous two-phase locking is even stricter. Here, all locks
are held till commit/abort. In this protocol transactions can be
serialized in the order in which they commit.

Database System Concepts - 6th Edition 15.15 ©Silberschatz, Korth and Sudarshan
 Implementation of Locking
 A lock manager can be implemented as a separate process to
which transactions send lock and unlock requests
 The lock manager replies to a lock request by sending a lock
grant messages (or a message asking the transaction to roll
back, in case of a deadlock)
 The requesting transaction waits until its request is answered
 The lock manager maintains a data-structure called a lock
table to record granted locks and pending requests
 The lock table is usually implemented as an in-memory hash
table indexed on the name of the data item being locked

Database System Concepts - 6th Edition 15.16 ©Silberschatz, Korth and Sudarshan
 Lock Table
 Dark blue rectangles indicate granted
locks; light blue 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 later requests are
checked to see if they can now be
granted
 If transaction aborts, all waiting or granted
requests of the transaction are deleted
 lock manager may keep a list of locks
held by each transaction, to
implement this efficiently

Database System Concepts - 6th Edition 15.17 ©Silberschatz, Korth and Sudarshan