Chapter 16: Concurrency Control

• Lock-Based Protocols
• Timestamp-Based Protocols
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 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.
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
 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.
If we do not use locking, or if we unlock data
items as soon as possible after reading or
writing them, we may get inconsistent states.
On the other hand, if we do not unlock a data
item before requesting a lock on another data
item, deadlocks may occur
 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.
 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
• Cascadeless schedules are desirable but 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.
 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.
Another method for determining the serializability order is to
select ordering among transactions in advance.

Most common method for doing so is to use a

timestamp-ordering scheme.
 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.
 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 the maximum of R-
timestamp(Q) and TS(Ti).
Timestamp-Based Protocols
(Cont.)
• Suppose that transaction Ti issues write(Q).
• 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.
• 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.
• Otherwise, the write operation is executed, and
W-timestamp(Q) is set to TS(Ti).
 Correctness of Timestamp-Ordering Protocol

• The timestamp-ordering protocol guarantees conflict

serializability since all the arcs in the precedence graph
are of the form:

transaction transactio
with smaller n
timestamp with larger
timestamp

Thus, there will be no cycles in the precedence graph

• Timestamp protocol ensures freedom from deadlock as
no transaction ever waits. But may lead to starvation of
a long transaction, if a set of short conflicting
transactions may cause repeated restarting of it.
• But the schedule may not be cascade-free, and may
not even be recoverable.
 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:
• 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
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}. Hence, 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.
Unlike previous protocols, it allows some view-serializable
schedules that are not conflict-serializable.