Concurrency Control

Concurrency Control
• Lock-Based Protocols
• Timestamp-Based Protocols
• Multiple Granularity
• Multiversion Schemes
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-compatibility matrix
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
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.
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.
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(shared
and exclusive) 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.
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
Example of Granularity Hierarchy

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

• database
• area
• file
• record
Deadlock Handling
• 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 (X)
wait for lock-X on X
wait for lock-X on Y
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).
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.
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.
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. 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
• 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 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
Other Approaches to
Concurrency Control
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 max(R-timestamp(Q), TS(Ti)).

Transaction T1 (100) Transaction T2 (200) Transaction T1 (100) Transaction T2 (200)

Write(Q) Read (Q)

Read (Q) Write(Q)

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

T1 (100) T2 (200) T1 (100) T2 (200) T1 (100) T2 (200)

Read (Q) Write(Q) Write(Q)

Write(Q) Write(Q) Read (Q)/

Write(Q)
Case 1 Case 2
Case 3
Correctness of Timestamp-Ordering Protocol
• The timestamp-ordering protocol guarantees serializability since all
the arcs in the precedence graph are of the form:

transaction transaction
with smaller with larger
timestamp timestamp

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