Chapter 4 : Concurrency Control

Techniques
 Chapter 4: Concurrency Control Techniques

 used to ensure the noninterference or isolation property of concurrently

executing transactions.
 Most of these techniques ensure serializability of schedules using
concurrency control protocols (sets of rules) that guarantee serializability.
 Protocols:
 two-phase locking protocols (used in most commercial DBMSs)
 Timestamp-Based Protocols
 Validation-Based Protocol
 multiversion concurrency control protocols
 Lock-Based Protocols
 A lock is a variable associated with a data item that describes the status of
the item with respect to possible operations that can be applied to it.
 Generally, there is one lock for each data item in the database.
 A lock is a mechanism to control concurrent access to a data item
 Types of locks:
 Binary locks (not used in practice)
 Shared/exclusive locks (read/write locks)
 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(lock manager).
 Transaction can proceed only after request is granted.
Shared/Exclusive (or Read/Write) Locks
 We should allow several transactions to access the same item X if they all
access X for reading purposes only.
 This is because read operations on the same item by different transactions
are not conflicting.
 However, if a transaction is to write an item X, it must have exclusive
access to X.
 there are three locking operations:
 read_lock(X) or lock-S(X)
 write_lock(X) or lock-X(X), and
 unlock(X)
 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 waiting transaction is placed in a waiting queue for the item
 Once 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 number 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.
 Deadlock occurs when each transaction T in a set of two or more
transactions is waiting for some item that is locked by some other
transaction T ‘ in the set.
 To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.
 Pitfalls of Lock-Based Protocols (Cont.)
 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.
 occurs when a transaction cannot proceed for an indefinite period of time
while other transactions in the system continue normally.
 Concurrency control manager can be designed to prevent starvation.
 One solution for starvation is to have a fair waiting scheme, such as using
a first-come-first-served queue;
 transactions are enabled to lock an item in the order in which they originally requested the
lock.

 Another scheme allows some transactions to have priority over others but
increases the priority of a transaction the longer it waits, until it eventually
gets the highest priority and proceeds.
 The Two-Phase Locking Protocol (2PL)
 This is a protocol which ensures conflict-serializable schedules.
 Requires each Transaction to issue lock and unlock requests in 2
phases:
 Phase 1: Growing/ expanding Phase
 transaction can obtain locks
 transaction can not release existing locks
 Phase 2: Shrinking Phase
 transaction can release existing locks
 transaction can not obtain locks
 Initially, a transaction is in the growing phase. The transaction
acquires locks as needed.
 Once the transaction releases a lock, it enters the shrinking phase,
and it can issue no more lock requests.
 if every transaction in a schedule follows the two-phase locking
protocol, the schedule is guaranteed to be serializable.
 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.)
 The Basic Two-phase locking does not ensure freedom from deadlocks

 Cascading roll-back is possible under two-phase locking.

 If Transaction T is aborted and rolled back, any Transaction T1 that may
have used a value written by T must also be rolled back. Similarly, any
Transaction T2 that may have used a value written by T1 must also be rolled
back, and so on.
In this partial schedule each
Transaction observes the 2PL
protocol, but the failure of T5
after the read(A) step of T7 leads
to cascading rollback of T6 and
T7.
 conservative 2PL (or static 2PL) requires a transaction to lock all the
items it accesses before the transaction begins execution, by
predeclaring its read-set and write-set.
 If any of the predeclared items needed cannot be locked, the
transaction does not lock any item; instead, it waits until all the items
are available for locking.
 Conservative 2PL is a deadlock-free protocol.
 In practice, the most popular variation of 2PL is strict 2PL, which
guarantees strict schedules.
 In strict 2PL a transaction must hold all its exclusive locks till it
commits/aborts.
 Hence, no other transaction can read or write an item that is written by
T unless T has committed, leading to a strict schedule for
recoverability.
 It avoids cascading roll-back.
 Strict 2PL is not deadlock-free.
 Rigorous two-phase locking is even stricter and guarantees strict
schedules:
 here all locks are held till commit/abort.
 a transaction T does not release any of its locks (exclusive or
shared) until after it commits or aborts, and so it is easier to
implement than strict 2PL.
 In this protocol transactions can be serialized in the order in which
they commit.
 Most database systems implement either strict or rigorous two-phase
locking.
 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)
 Lock conversion can not be allowed arbitrarily.
 Rather, upgrading can take place in only the growing phase, whereas
downgrading can take place only in the shrinking phase.
 This protocol assures serializability. But still relies on the programmer to
insert the various locking instructions.
 Automatic Acquisition of Locks
 In many cases, the concurrency control subsystem itself is
responsible for generating the read_lock and write_lock requests.
 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
 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 trans. 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
 Implementation of Locking
 A lock manager can be implemented as a 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 manager maintains a linked list of records, one for each
request, in the order in which the requests arrived. => lock table
 The lock table is usually implemented as an in-memory hash table
indexed on the name of the data item being locked
Lock Table  The table contains locks for five different
data items, I4, I7, I23, I44, and I912
 Black rectangles indicate granted locks,
white ones indicate waiting requests
 T23 has been granted locks on I7 and
I912, and is waiting for a lock on I4.
 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
Granted
 If transaction aborts, all waiting or
Waiting granted requests of the transaction are
deleted
 lock manager may keep a list of
locks held by each transaction, to
implement this efficiently
 Granularity of Data Items
 All concurrency control techniques assume that the database is
formed of a number of named data items.
 A database item could be chosen to be one of the following:
 A database record
 A field value of a database record
 A disk block
 A whole file
 The whole database

 The data item granularity is the size of data items.

 The granularity can affect the performance of concurrency control and
recovery.
 Can be represented graphically as a tree
 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):
 Refers to small item sizes
 high concurrency, high locking overhead

 coarse granularity (higher in tree):

 Refers to large item sizes
 low locking overhead, low degree of concurrency
 Example of Granularity Hierarchy

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

 database
 Area/ block
 file
 record
 Intention Lock Modes
 In addition to S and X lock modes, there are three additional lock
modes with multiple granularity locking schemes:
 intention-shared (IS): indicates explicit locking at a lower level of
the tree but only with shared locks.
 indicates that one or more shared locks will be requested on
some descendant node(s).
 intention-exclusive (IX): indicates explicit locking at a lower level
with exclusive or shared locks
 indicates that one or more exclusive locks will be requested on
some descendant node(s).
 Shared-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.
 indicates that the current node is locked in shared mode but
that one or more exclusive locks will be requested on some
descendant node(s).
 intention locks allow a higher level node to be locked in S or X mode
without having to check all descendent nodes.
 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     
 Multiple Granularity Locking Scheme (MGL)
 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 IS or IX 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)-> enforce the 2PL protocol.
6. Ti can unlock a node Q only if none of the children of Q are currently
locked by Ti.
 Observe that locks are acquired in root-to-leaf order, whereas they are
released in leaf-to-root order.
 The multiple granularity level protocol is especially suited when processing a
mix of transactions that include
 short transactions that access only a few items (records or fields) and
 long transactions that access entire files.
 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.
 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
 There are two principal methods for dealing with the deadlock problem.
 Deadlock prevention
 Deadlock detection and Deadlock recovery
 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).
 This is generally not a practical assumption—if any of the items
cannot be obtained, none of the items are locked.
 limits concurrency.
 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).
 This requires that the programmer (or the system) is aware of the
chosen order of the items, which is also not practical in the
database context.
 More Deadlock Prevention Strategies
 Following schemes use transaction timestamps for the sake of deadlock
prevention alone.
 Transaction timestamp is a unique identifier assigned to each
transaction. It is based on the order in which transactions are started.
 There are two deadlock prevention schemes using timestamps:
 wait-die scheme — non-preemptive
 older transaction(with smaller timestamp) 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
 Transactions only wait for younger ones so no cycle is created.
For Example: suppose that transactions T22, T23, and T24 have timestamps
5,10,and 15,respectively.
 If T22 requests a data item held by T23, then T22 will wait.
 If T24 requests a data item held by T23, then T24 will be rolled back.
 wound-wait scheme — preemptive
 older transaction wounds (forces rollback of) younger transaction by
aborting it instead of waiting for it.
 Younger transactions may wait for older ones.
 may be fewer rollbacks than wait-die scheme.
For Example: suppose that transactions T22, T23, and T24 have timestamps
5,10,and 15,respectively.
 If T22 requests a data item held by T23, then T22 preempts T23 , and T23
will be rolled back.
 If T24 requests a data item held by T23, then T24 will wait.
 Both schemes end up aborting the younger of the two transactions (the
transaction that started later) that may be involved in a deadlock, assuming
that this will waste less processing.
 Deadlock prevention (Cont.)
 Both in wait-die and in wound-wait schemes, a rolled back transaction
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.
 Deadlock Detection
 A second, more practical approach to dealing with deadlock is deadlock
detection, where the system checks if a state of deadlock actually exists.
 A simple way to detect a state of deadlock is for the system to construct
and maintain a wait-for graph.
 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 detected)
 Deadlock Recovery
 When deadlock is detected :
 some of the transactions causing the deadlock must be aborted (rolled
back).
 Choosing which transactions to abort is known as victim selection.
 The algorithm for victim selection should generally avoid selecting
transactions that have been running for a long time and that have
performed many updates, and it should try instead to select transactions
that have not made many changes (younger transactions rather than older
ones).
 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( causing
it to abort and never finish execution).
 Include the number of rollbacks in the cost factor to avoid starvation by
giving higher priorities for transactions that have been aborted multiple
times.