Chapter 15 : Concurrency Control

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Outline
 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
 Objectives
 To ensure only serializable schedules are generated
 recoverable and cascadless schdules are ensured

Database System Concepts - 6th Edition 15.3 ©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 the concurrency-
control manager by the programmer. Transaction
can proceed only after request is granted.

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

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

Database System Concepts - 6th Edition 15.8 ©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.9 ©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.10 ©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 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

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

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

Database System Concepts - 6th Edition 15.14 ©Silberschatz, Korth and Sudarshan
 Two-Phase Locking Techniques

 Two-phase policy generates two locking algorithms


(a) Basic
 (b) Conservative
 Conservative:
 Prevents deadlock by locking all desired data
items before transaction begins execution.
 Basic:
 Transaction locks data items incrementally.
This may cause deadlock which is dealt with.
 Strict:
 A more stricter version of Basic algorithm
where unlocking is performed after a
transaction terminates (commits or aborts and
rolled-back). This is the most commonly used
two-phase locking algorithm.
 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.
Slide 18- 15
Database System Concepts - 6th Edition 15.15 ©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.16 ©Silberschatz, Korth and Sudarshan
 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

Database System Concepts - 6th Edition 15.17 ©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.

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

Database System Concepts - 6th Edition 15.19 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Dealing with Deadlock and Starvation
 Starvation
 Starvation occurs when a particular
transaction consistently waits or restarted
and never gets a chance to proceed further.
 In a deadlock resolution it is possible that
the same transaction may consistently be
selected as victim and rolled-back.
 This limitation is inherent in all priority
based scheduling mechanisms.
 In Wound-Wait scheme a younger
transaction may always be wounded
(aborted) by a long running older
transaction which may create starvation.

Slide 18- 20
Database System Concepts - 6th Edition 15.20 ©Silberschatz, Korth and Sudarshan
 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. 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 good value of the timeout
interval.

Database System Concepts - 6th Edition 15.21 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Dealing with Deadlock and Starvation
 Deadlock prevention
 A transaction locks all data items it refers to before
it begins execution.
 This way of locking prevents deadlock since a
transaction never waits for a data item.
 The conservative two-phase locking uses this
approach.

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

Database System Concepts - 6th Edition 15.23 ©Silberschatz, Korth and Sudarshan
 Deadlock Detection (Cont.)

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

Database System Concepts - 6th Edition 15.24 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control

Dealing with Deadlock and Starvation

 Deadlock detection and resolution
 In this approach, deadlocks are allowed to
happen. The scheduler maintains a wait-
for-graph for detecting cycle. If a cycle
exists, then one transaction involved in the
cycle is selected (victim) and rolled-back.
 A wait-for-graph is created using the lock
table. As soon as a transaction is blocked,
it is added to the graph. When a chain like:
Ti waits for Tj waits for Tk waits for Ti or Tj
occurs, then this creates a cycle. One of
the transaction is rolled back.

Slide 18- 25
Database System Concepts - 6th Edition 15.25 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control

Dealing with Deadlock and Starvation

 Deadlock avoidance
 There are many variations of two-phase
locking algorithm.
 Some avoid deadlock by not letting the
cycle to complete.
 That is as soon as the algorithm discovers
that blocking a transaction is likely to
create a cycle, it rolls back the transaction.
 Wound-Wait and Wait-Die algorithms use
timestamps to avoid deadlocks by rolling-
back victim.

Slide 18- 26
Database System Concepts - 6th Edition 15.26 ©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.27 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Timestamp based concurrency control algorithm
 Timestamp
 A monotonically increasing variable (integer)
indicating the age of an operation or a transaction. A
larger timestamp value indicates a more recent event
or operation.
 Timestamp based algorithm uses timestamp to
serialize the execution of concurrent transactions.

Slide 18- 28
Database System Concepts - 6th Edition 15.28 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Timestamp based concurrency control
algorithm
 Basic Timestamp Ordering
 1. Transaction T issues a write_item(X)
operation:
 If read_TS(X) > TS(T) or if write_TS(X) > TS(T),
then an younger transaction has already read
the data item so abort and roll-back T and
reject the operation.
 If the condition in part (a) does not exist,
then execute write_item(X) of T and set
write_TS(X) to TS(T).
 2. Transaction T issues a read_item(X)
operation:
 If write_TS(X) > TS(T), then an younger
transaction has already written to the data
item so abort and roll-back T and reject
Slidethe
18- 29
Database System Concepts - 6th Edition 15.29 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Timestamp based concurrency control algorithm
 Strict Timestamp Ordering
 1. Transaction T issues a write_item(X) operation:
 If TS(T) > read_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).
 2. Transaction T issues a read_item(X) operation:
 If TS(T) > write_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).

Slide 18- 30
Database System Concepts - 6th Edition 15.30 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Timestamp based concurrency control algorithm
 Thomas’s Write Rule
 If read_TS(X) > TS(T) then abort and roll-back T and
reject the operation.
 If write_TS(X) > TS(T), then just ignore the write
operation and continue execution. This is because
the most recent writes counts in case of two
consecutive writes.
 If the conditions given in 1 and 2 above do not occur,
then execute write_item(X) of T and set write_TS(X)
to TS(T).

Slide 18- 31
Database System Concepts - 6th Edition 15.31 ©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.32 ©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.33 ©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.34 ©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.35 ©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
Database System Concepts - 6th Edition 15.36 ©Silberschatz, Korth and Sudarshan
 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.

Database System Concepts - 6th Edition 15.37 ©Silberschatz, Korth and Sudarshan
 Insert and Delete Operations
 If two-phase locking is used :
 A delete operation may be performed only if the
transaction deleting the tuple has an exclusive lock
on the tuple to be deleted.
 A transaction that inserts a new tuple into the
database is given an X-mode lock on the tuple
 Insertions and deletions can lead to the phantom
phenomenon.
 A transaction that scans a relation
 (e.g., find sum of balances of all accounts in
Perryridge)
and a transaction that inserts a tuple in the relation
 (e.g., insert a new account at Perryridge)

(conceptually) conflict in spite of not accessing any

tuple in common.
 If only tuple locks are used, non-serializable
schedules can result
 E.g. the scan transaction does not see the new
account, but reads some other tuple written by the
Database System Concepts - 6update
th
Edition transaction 15.38 ©Silberschatz, Korth and Sudarshan
 Deadlocks
 Consider the following two transactions:
T1: write (X) T2: write(Y)
write(Y) write(X)

 Schedule with deadlock

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