Unit-IV

Concurrency Control &

Deadlock
Prof. Atul Barve
Prestige Institute of Engineering, Management & Research, Indore

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

2
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
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
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).

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

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

7
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

8
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
9
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.
10
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.

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

12
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

13
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
14
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.

15
More Deadlock Prevention Strategies
● 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 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. (older
means smaller timestamp) Younger transactions never Younger
transactions never wait for older ones; they are rolled back instead.
 a transaction may die several times before acquiring needed data item

16
More Deadlock Prevention Strategies
● 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.
 Partial ordering of all data items and require that a transaction can lock
data items only in the order specified by the partial order.
● 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. If the
lock has not been granted within that time, the transaction is rolled back
and restarted,
 Thus, deadlocks are not possible
 simple to implement; but starvation is possible. Also difficult to determine
17
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.

18
Deadlock Detection (Cont.)

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

19
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

20
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.
● When a transaction locks a node in the tree explicitly, it implicitly locks all the
node's descendants 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

21
Example of Granularity Hierarchy
● The levels, starting from the coarsest (top) level are
 database
 area
 file
 record

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

23
Compatibility Matrix with Intention Lock
Modes
● The compatibility matrix for all lock modes is:

24
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).
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.
● Lock granularity escalation: in case there are too many locks at a
25
Timestamp-Based Protocols
● Each transaction is issued a timestamp when it enters the system. If an old
transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-
stamp TS(Tj) such that TS(Ti) <TS(Tj).
● The protocol manages concurrent execution such that the time-stamps
determine the serializability order.
● In order to assure such behavior, the protocol maintains for each data Q two
timestamp values:
 W-timestamp(Q) is the largest time-stamp of any transaction that
executed write(Q) successfully.
 R-timestamp(Q) is the largest time-stamp of any transaction that
executed read(Q) successfully.

26
Timestamp-Based Protocols (Cont.)
● The timestamp ordering protocol ensures that any conflicting read and write
operations are executed in timestamp order.
● Suppose a transaction Ti issues a read(Q)
1. If TS(Ti)  W-timestamp(Q), then Ti needs to read a value of Q that was
already overwritten.
 Hence, the read operation is rejected, and Ti is rolled back.
2. If TS(Ti)  W-timestamp(Q), then the read operation is executed, and R-
timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).

27
Timestamp-Based Protocols (Cont.)
● Suppose that transaction Ti issues write(Q).
1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was
needed previously, and the system assumed that that value would never
be produced.
 Hence, the write operation is rejected, and Ti is rolled back.
2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value
of Q.
 Hence, this write operation is rejected, and Ti is rolled back.
3. Otherwise, the write operation is executed, and W-timestamp(Q) is set to
TS(Ti).

28
Example Use of the Protocol
● A partial schedule for several data items for transactions with timestamps 1,
2, 3, 4, 5

29
Correctness of Timestamp-Ordering
Protocol
● The timestamp-ordering protocol guarantees serializability since all the arcs in
the precedence graph are of the form:

Thus, there will be no cycles in the precedence graph

● Timestamp protocol ensures freedom from deadlock as no transaction ever
waits.
● But the schedule may not be cascade-free, and may not even be recoverable.

30
Recoverability and Cascade Freedom
● Problem with timestamp-ordering protocol:
 Suppose Ti aborts, but Tj has read a data item written by Ti
 Then Tj must abort; if Tj had been allowed to commit earlier, the schedule
is not recoverable.
 Further, any transaction that has read a data item written by Tj must abort
 This can lead to cascading rollback --- that is, a chain of rollbacks
● Solution 1:
 A transaction is structured such that its writes are all performed at the end
of its processing
 All writes of a transaction form an atomic action; no transaction may
execute while a transaction is being written
 A transaction that aborts is restarted with a new timestamp
● Solution 2: Limited form of locking: wait for data to be committed before
reading it
● Solution 3: Use commit dependencies to ensure recoverability 31
Thomas Write Rule
● Modified version of the timestamp-ordering protocol in which obsolete write
operations may be ignored under certain circumstances.
● When Ti attempts to write data item Q, if TS(Ti) < W-timestamp(Q), then Ti is
attempting to write an obsolete value of {Q}.
 Rather than rolling back Ti as the timestamp ordering protocol would have
done, this {write} operation can be ignored.
● Otherwise this protocol is the same as the timestamp ordering protocol.
● Thomas' Write Rule allows greater potential concurrency.
 Allows some view-serializable schedules that are not conflict-serializable.

32
Validation-Based Protocol
● Execution of transaction Ti is done in three phases.
1. Read and execution phase: Transaction Ti writes only to
temporary local variables
2. Validation phase: Transaction Ti performs a ''validation test''
to determine if local variables can be written without violating
serializability.
3. Write phase: If Ti is validated, the updates are applied to the
database; otherwise, Ti is rolled back.
● The three phases of concurrently executing transactions can be interleaved,
but each transaction must go through the three phases in that order.
 Assume for simplicity that the validation and write phase occur together,
atomically and serially
o I.e., only one transaction executes validation/write at a time.
● Also called as optimistic concurrency control since transaction executes
fully in the hope that all will go well during validation 33
Validation-Based Protocol (Cont.)
● Each transaction Ti has 3 timestamps
 Start(Ti) : the time when Ti started its execution
 Validation(Ti): the time when Ti entered its validation phase
 Finish(Ti) : the time when Ti finished its write phase
● Serializability order is determined by timestamp given at validation time; this
is done to increase concurrency.
 Thus, TS(Ti) is given the value of Validation(Ti).
● This protocol is useful and gives greater degree of concurrency if probability of
conflicts is low.
 because the serializability order is not pre-decided, and
 relatively few transactions will have to be rolled back.

34
Validation Test for Transaction Tj
● If for all Ti with TS (Ti) < TS (Tj) either one of the
following condition holds:
 finish(Ti) < start(Tj)
 start(Tj) < finish(Ti) < validation(Tj) and
the set of data items written by Ti does not
intersect with the set of data items read by
T j.
then validation succeeds and Tj can be
committed. Otherwise, validation fails and Tj is
aborted.
● Justification: Either the first condition is Schedule Produced by Validation
Example of schedule produced using
satisfied, and there is no overlapped execution, validation
or the second condition is satisfied and
 the writes of Tj do not affect reads of Ti since
35
Multiversion Schemes
● Multiversion schemes keep old versions of data item to increase concurrency.
 Multiversion Timestamp Ordering
 Multiversion Two-Phase Locking
● Each successful write results in the creation of a new version of the data item
written.
● Use timestamps to label versions.
● When a read(Q) operation is issued, select an appropriate version of Q based
on the timestamp of the transaction, and return the value of the selected
version.
● reads never have to wait as an appropriate version is returned immediately.

36
Multiversion Timestamp Ordering
● Each data item Q has a sequence of versions <Q1, Q2,...., Qm>. Each version
Qk contains three data fields:
 Content -- the value of version Qk.
 W-timestamp(Qk) -- timestamp of the transaction that created (wrote)
version Qk
 R-timestamp(Qk) -- largest timestamp of a transaction that successfully
read version Qk
● When a transaction Ti creates a new version Qk of Q, Qk's W-timestamp and R-
timestamp are initialized to TS(Ti).
● R-timestamp of Qk is updated whenever a transaction Tj reads Qk, and TS(Tj) >
R-timestamp(Qk).

37
Multiversion Timestamp Ordering (Cont)
● Suppose that transaction Ti issues a read(Q) or write(Q) operation. Let Qk
denote the version of Q whose write timestamp is the largest write timestamp
less than or equal to TS(Ti).
1. If transaction Ti issues a read(Q), then the value returned is the content
of version Qk.
2. If transaction Ti issues a write(Q)
I. if TS(Ti) < R-timestamp(Qk), then transaction Ti is rolled back.
II. if TS(Ti) = W-timestamp(Qk), the contents of Qk are overwritten
III. else a new version of Q is created.
● Observe that
 Reads always succeed
 A write by Ti is rejected if some other transaction Tj that (in the serialization
order defined by the timestamp values) should read
Ti's write, has already read a version created by a transaction older than Ti.
38
Multiversion Two-Phase Locking
● Differentiates between read-only transactions and update transactions
● Update transactions acquire read and write locks, and hold all locks up to the
end of the transaction. That is, update transactions follow rigorous two-phase
locking.
 Each successful write results in the creation of a new version of the data
item written.
 Each version of a data item has a single timestamp whose value is
obtained from a counter ts-counter that is incremented during commit
processing.
● Read-only transactions are assigned a timestamp by reading the current value
of ts-counter before they start execution; they follow the multiversion
timestamp-ordering protocol for performing reads.

39
Multiversion Two-Phase Locking (Cont.)
● When an update transaction wants to read a data item:
 it obtains a shared lock on it, and reads the latest version.
● When it wants to write an item
 it obtains X lock on; it then creates a new version of the item and sets this
version's timestamp to .
● When update transaction Ti completes, commit processing occurs:
 Ti sets timestamp on the versions it has created to ts-counter + 1
 Ti increments ts-counter by 1
● Read-only transactions that start after Ti increments ts-counter will see the
values updated by Ti.
● Read-only transactions that start before Ti increments the ts-counter will see
the value before the updates by Ti.
● Only serializable schedules are produced.

40
MVCC: Implementation Issues
● Creation of multiple versions increases storage overhead
 Extra tuples
 Extra space in each tuple for storing version information
● Versions can, however, be garbage collected
 E.g. if Q has two versions Q5 and Q9, and the oldest active transaction has
timestamp > 9, than Q5 will never be required again

41
Snapshot Isolation
● Motivation: Decision support queries that read large amounts of data have
concurrency conflicts with OLTP transactions that update a few rows
 Poor performance results
● Solution 1: Give logical “snapshot” of database state to read only
transactions, read-write transactions use normal locking
 Multiversion 2-phase locking
 Works well, but how does system know a transaction is read only?
● Solution 2: Give snapshot of database state to every transaction, updates
alone use 2-phase locking to guard against concurrent updates
 Problem: variety of anomalies such as lost update can result
 Partial solution: snapshot isolation level (next slide)
o Proposed by Berenson et al, SIGMOD 1995
o Variants implemented in many database systems
 E.g. Oracle, PostgreSQL, SQL Server 2005

42
Benefits of Snapshot Isolation
● Reading is never blocked,
 and also doesn’t block other txns activities
● Performance similar to Read Committed
● Avoids the usual anomalies
 No dirty read
 No lost update
 No non-repeatable read
 Predicate based selects are repeatable (no phantoms)
● Problems with SI
 SI does not always give serializable executions
o Serializable: among two concurrent txns, one sees the effects of the
other
o In SI: neither sees the effects of the other
 Result: Integrity constraints can be violated

43
Snapshot Isolation Anomalies
● SI breaks serializability when txns modify different items, each based on a
previous state of the item the other modified
 Not very common in practice
o E.g., the TPC-C benchmark runs correctly under SI
o when txns conflict due to modifying different data, there is usually also
a shared item they both modify too (like a total quantity) so SI will
abort one of them
 But does occur
o Application developers should be careful about write skew
● SI can also cause a read-only transaction anomaly, where read-only
transaction may see an inconsistent state even if updaters are serializable
 We omit details
● Using snapshots to verify primary/foreign key integrity can lead to
inconsistency
 Integrity constraint checking usually done outside of snapshot
44
Index Locking Protocol
● Index locking protocol:
 Every relation must have at least one index.
 A transaction can access tuples only after finding them through one or
more indices on the relation
 A transaction Ti that performs a lookup must lock all the index leaf nodes
that it accesses, in S-mode
o Even if the leaf node does not contain any tuple satisfying the index
lookup (e.g. for a range query, no tuple in a leaf is in the range)
 A transaction Ti that inserts, updates or deletes a tuple ti in a relation r
o must update all indices to r
o must obtain exclusive locks on all index leaf nodes affected by the
insert/update/delete
 The rules of the two-phase locking protocol must be observed
● Guarantees that phantom phenomenon won’t occur
45
Next-Key Locking
● Index-locking protocol to prevent phantoms required locking entire leaf
 Can result in poor concurrency if there are many inserts
● Alternative: for an index lookup
 Lock all values that satisfy index lookup (match lookup value, or fall in
lookup range)
 Also lock next key value in index
 Lock mode: S for lookups, X for insert/delete/update
● Ensures that range queries will conflict with inserts/deletes/updates
 Regardless of which happens first, as long as both are concurrent

46
Concurrency in Index Structures
● Indices are unlike other database items in that their only job is to help in
accessing data.
● Index-structures are typically accessed very often, much more than other
database items.
 Treating index-structures like other database items, e.g. by 2-phase
locking of index nodes can lead to low concurrency.
● There are several index concurrency protocols where locks on internal nodes
are released early, and not in a two-phase fashion.
 It is acceptable to have non-serializable concurrent access to an index as
long as the accuracy of the index is maintained.
o In particular, the exact values read in an internal node of a B+-tree are
irrelevant so long as we land up in the correct leaf node.

47
Concurrency in Index Structures (Cont.)
● Example of index concurrency protocol:
● Use crabbing instead of two-phase locking on the nodes of the B+-tree, as
follows. During search/insertion/deletion:
 First lock the root node in shared mode.
 After locking all required children of a node in shared mode, release the lock
on the node.
 During insertion/deletion, upgrade leaf node locks to exclusive mode.
 When splitting or coalescing requires changes to a parent, lock the parent in
exclusive mode.
● Above protocol can cause excessive deadlocks
 Searches coming down the tree deadlock with updates going up the tree
 Can abort and restart search, without affecting transaction
● Better protocols are available; see Section 16.9 for one such protocol, the B-link
tree protocol
 Intuition: release lock on parent before acquiring lock on child
48
Weak Levels of Consistency
● Degree-two consistency: differs from two-phase locking in that S-locks may
be released at any time, and locks may be acquired at any time
 X-locks must be held till end of transaction
 Serializability is not guaranteed, programmer must ensure that no
erroneous database state will occur]
● Cursor stability:
 For reads, each tuple is locked, read, and lock is immediately released
 X-locks are held till end of transaction
 Special case of degree-two consistency

49
Weak Levels of Consistency in SQL
● SQL allows non-serializable executions
 Serializable: is the default
 Repeatable read: allows only committed records to be read, and
repeating a read should return the same value (so read locks should be
retained)
o However, the phantom phenomenon need not be prevented
 T1 may see some records inserted by T2, but may not see others
inserted by T2
 Read committed: same as degree two consistency, but most systems
implement it as cursor-stability
 Read uncommitted: allows even uncommitted data to be read
● In many database systems, read committed is the default consistency level
 has to be explicitly changed to serializable when required
o set isolation level serializable

50