Chapter 16 : Concurrency Control

Database Management Systems (INFSCI 1022)

Textbook: Database System Concepts - 5th Edition, 2005

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 concurrency-control manager. Transaction can
proceed only after request is granted.

2
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

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

3
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

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.

4
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

2
 Pitfalls of Lock-Based Protocols
 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.

5
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

Pitfalls of Lock-Based Protocols (Cont.)

 The potential for deadlock exists in most locking protocols. Deadlocks

are a necessary evil.
 Starvation is also possible if 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.

6
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

3
 The Two-Phase Locking Protocol
 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
 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).

7
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

The Two-Phase Locking Protocol (Cont.)

 Two-phase locking does not ensure freedom from deadlocks

 Cascading roll-back is possible under two-phase locking. To avoid
this, follow a modified protocol called strict two-phase locking. Here
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.

8
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

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

9
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

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.

10
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

5
 Multiple Granularity
 Allow data items to be of various sizes and define a hierarchy of data
granularities, where the small granularities are nested within larger
ones
 Can be represented graphically as a tree (but don't confuse with tree-
locking protocol)
 When a transaction locks a node in the tree explicitly, it implicitly locks
all the node's descendents in the same mode.
 Granularity of locking (level in tree where locking is done):
 fine granularity (lower in tree): high concurrency, high locking
overhead
 coarse granularity (higher in tree): low locking overhead, low
concurrency

11
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

Example of Granularity Hierarchy

The levels, starting from the coarsest (top) level are

 database
 area
 file
 record
12
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

6
 Intention Lock Modes
 In addition to S and X lock modes, there are three additional lock
modes with multiple granularity:
 intention-shared (IS): indicates explicit locking at a lower level of
the tree but only with shared locks.
 intention-exclusive (IX): indicates explicit locking at a lower level
with exclusive or shared locks
 shared and intention-exclusive (SIX): the subtree rooted by that
node is locked explicitly in shared mode and explicit locking is
being done at a lower level with exclusive-mode locks.
 intention locks allow a higher level node to be locked in S or X mode
without having to check all descendent nodes.

13
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

Compatibility Matrix with

Intention Lock Modes
 The compatibility matrix for all lock modes is:

IS IX S S IX X
IS     ×

IX   × × ×

S  ×  × ×

S IX  × × × ×

X × × × × ×

14
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

7
 Multiple Granularity Locking Scheme
 Transaction Ti can lock a node Q, using the following rules:
1. The lock compatibility matrix must be observed.
2. The root of the tree must be locked first, and may be locked in any
mode.
3. A node Q can be locked by Ti in S or IS mode only if the parent of Q
is currently locked by Ti in either IX or IS mode.
4. A node Q can be locked by Ti in X, SIX, or IX mode only if the parent
of Q is currently locked by Ti in either IX or SIX mode.
5. Ti can lock a node only if it has not previously unlocked any node
(that is, Ti is two-phase).
Ti can unlock a node Q only if none of the children of Q are currently
6.
locked by Ti.
 Observe that locks are acquired in root-to-leaf order, whereas they are
released in leaf-to-root order.

15
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

Deadlock Handling
 Consider the following two transactions:
T1: write (X) T2: write(Y)
write(Y) write(X)
 Schedule with deadlock

T1 T2

lock-X on X
write (X)
lock-X on Y
write (X)
wait for lock-X on X
wait for lock-X on Y

16
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

8
 Deadlock Handling
 System is deadlocked if there is a set of transactions such that every
transaction in the set is waiting for another transaction in the set.
 Deadlock prevention protocols ensure that the system will never
enter into a deadlock state. Some prevention strategies :
 Require that each transaction locks all its data items before it
begins execution (predeclaration).
 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 (graph-based protocol).

17
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

More Deadlock Prevention Strategies

 Following schemes use transaction timestamps for the sake of deadlock
prevention alone.
 wait-die scheme — non-preemptive
 older transaction may wait for younger one to release data item.
Younger transactions never wait for older ones; they are rolled back
instead.
 a transaction may die several times before acquiring needed data
item
 wound-wait scheme — preemptive
 older transaction wounds (forces rollback) of younger transaction
instead of waiting for it. Younger transactions may wait for older
ones.
 may be fewer rollbacks than wait-die scheme.

18
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

9
 Deadlock prevention (Cont.)
 Both in wait-die and in wound-wait schemes, a rolled back
transactions is restarted with its original timestamp. Older transactions
thus have precedence over newer ones, and starvation is hence
avoided.
 Timeout-Based Schemes :
 a transaction waits for a lock only for a specified amount of time.
After that, the wait times out and the transaction is rolled back.
 thus deadlocks are not possible
 simple to implement; but starvation is possible. Also difficult to
determine good value of the timeout interval.

19
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

Deadlock Detection
 Deadlocks can be described as a wait-for graph, which consists of a
pair G = (V,E),
 V is a set of vertices (all the transactions in the system)
 E is a set of edges; each element is an ordered pair Ti →Tj.
 If Ti → Tj is in E, then there is a directed edge from Ti to Tj, implying
that Ti is waiting for Tj to release a data item.
 When Ti requests a data item currently being held by Tj, then the edge
Ti Tj is inserted in the wait-for graph. This edge is removed only when
Tj is no longer holding a data item needed by Ti.
 The system is in a deadlock state if and only if the wait-for graph has a
cycle. Must invoke a deadlock-detection algorithm periodically to look
for cycles.

20
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

10
 Deadlock Detection (Cont.)

Wait-for graph without a cycle Wait-for graph with a cycle

21
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

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.
 Rollback -- determine how far to roll back transaction
 Total rollback: Abort the transaction and then restart it.
 More effective to roll back transaction only as far as necessary
to break deadlock.
 Starvation happens if same transaction is always chosen as
victim. Include the number of rollbacks in the cost factor to avoid
starvation

22
Textbook: Database System Concepts - 5th Edition, 2005 INFSCI 1022

11
 End of Chapter

Database Management Systems (INFSCI 1022)

Textbook: Database System Concepts - 5th Edition, 2005

23

12