Chapter 16 : Concurrency Control

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.
 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 lock 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.
 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.
 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.
 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 a 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.
 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).
 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.
 Lock Conversions
● Two-phase locking with lock conversions:

– First Phase: (Growing 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: (Shrinking 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.

 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

| 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 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
Granted each transaction, to implement this
efficiently
Waiting

| 11
 Graph-Based Protocols
● Graph-based protocols are an alternative to two-phase locking
● Impose a partial ordering → on the set D = {d1, d2 ,..., dh} of all data items.
● If di → dj then any transaction accessing both di and dj must access di before
accessing dj.
● Implies that the set D may now be viewed as a directed acyclic graph, called a
database graph.
● The tree-protocol is a simple kind of graph protocol.
 Tree Protocol

1. Only exclusive locks are allowed.

2. The first lock by Ti may be on any data item. Subsequently, a data Q can be
locked by Ti only if the parent of Q is currently locked by Ti.
3. Data items may be unlocked at any time.
4. A data item that has been locked and unlocked by Ti cannot subsequently be
relocked by Ti
 Graph-Based Protocols (Cont.)
● The tree protocol ensures conflict serializability as well as freedom from
deadlock.
● Unlocking may occur earlier in the tree-locking protocol than in the two-phase locking
protocol.
● shorter waiting times, and increase in concurrency
● protocol is deadlock-free, no rollbacks are required
● Drawbacks
● Protocol does not guarantee recoverability or cascade freedom
● Need to introduce commit dependencies to ensure recoverability
● Transactions may have to lock data items that they do not access.
● increased locking overhead, and additional waiting time
● potential decrease in concurrency
 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 descendants (children) in the same node.
● 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
 Example of Granularity Hierarchy

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

● database
● area
● file
● record
 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 (Y)
wait for lock-X on X
wait for lock-X on Y
 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 (pre-declaration).
● 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).
 Deadlock Prevention Strategies
● Following schemes use transaction timestamps for the sake of deadlock prevention
alone.

● wait-die scheme
● When an older transaction tries to lock a DB element that has been locked by
a younger transaction, it waits.
● When a younger transaction tries to lock a DB element that has been locked by
an older transaction, it dies.

● wound-wait scheme
● When an older transaction tries to lock a DB element that has been locked by
a younger transaction, it wounds (forces rollback) the younger transaction.
● When a younger transaction tries to lock a DB element that has been locked by
an older transaction, it waits.
 Deadlock Prevention Strategies (conti…)
• Difference between wait-die and wound-wait:

• In wait-die, the newer transactions are killed when the newer transaction
makes a request for a lock being held by an older transactions.

• In wound-wait, The newer transactions are killed when an older

transaction makes a request for a lock being held by the newer transactions.

• In both the schemes, only the transaction that enters the system at
a later timestamp (i.e. the younger transaction) is killed (wounded) and
restarted (Died).

• A rolled back transaction is restarted with its original timestamp.

 Deadlock prevention (Cont….)

● 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.
 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.
 Deadlock Detection (Cont.)

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

 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 the same transaction is always chosen as victim. Include
the number of rollbacks in the cost factor to avoid starvation.
End of Chapter