Chapter 15 : Concurrency Control

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 15: Concurrency Control
 Lock-Based Protocols
 Timestamp-Based Protocols
 Validation-Based Protocols
 Multiple Granularity
 Multiversion Schemes
 Insert and Delete Operations
 Concurrency in Index Structures

Database System Concepts - 6th Edition 15.2 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 6th Edition 15.3 ©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.4 ©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.5 ©Silberschatz, Korth and Sudarshan
 Pitfalls of Lock-Based Protocols
 Consider the partial schedule

 Neither T nor T can make progress — executing lock-S(B)

3 4
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.6 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 6th Edition 15.7 ©Silberschatz, Korth and Sudarshan
 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).

Database System Concepts - 6th Edition 15.8 ©Silberschatz, Korth and Sudarshan
 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.

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

Database System Concepts - 6th Edition 15.12 ©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.13 ©Silberschatz, Korth and Sudarshan
 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).
 Deadlock prevention by ordering usually ensured
by careful programming of transactions

Database System Concepts - 6th Edition 15.14 ©Silberschatz, Korth and Sudarshan
 Deadlock Detection

 Deadlock detection algorithms used to detect deadlocks

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

Database System Concepts - 6th Edition 15.15 ©Silberschatz, Korth and Sudarshan
 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

Database System Concepts - 6th Edition 15.16 ©Silberschatz, Korth and Sudarshan
 Locking Extensions
 Multiple granularity locking:
 idea: instead of getting separate locks on each
record
 lock an entire page explicitly, implicitly
locking all records in the page, or
 lock an entire relation, implicitly locking all
records in the relation
 See book for details of multiple-granularity
locking

Database System Concepts - 6th Edition 15.17 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 6th Edition 15.18 ©Silberschatz, Korth and Sudarshan
 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)).

Database System Concepts - 6th Edition 15.19 ©Silberschatz, Korth and Sudarshan
 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).

Database System Concepts - 6th Edition 15.20 ©Silberschatz, Korth and Sudarshan
 Example Use of the Protocol
A partial schedule for several data items for
transactions with
timestamps 1, 2, 3, 4, 5

Database System Concepts - 6th Edition 15.21 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 6th Edition 15.22 ©Silberschatz, Korth and Sudarshan
 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
Database System Concepts - 6th Edition 15.23 ©Silberschatz, Korth and Sudarshan
 Validation-Based Protocols
 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
 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

Database System Concepts - 6th Edition 15.24 ©Silberschatz, Korth and Sudarshan
 Validation-Based Protocols (Cont.)
 Validation is based on timestamps, but with two
timestamps:
 start time
 validation time
 Details in book

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