Unit-4

Concurrency control Syllabus –

Lock based concurrency control (2PL, Deadlocks),
Time stamping methods, optimistic methods,
database recovery management.
► Another category of techniques for the implementation of
isolation assigns each transaction a timestamp, typically when it
begins.
► For each data item, the system keeps two timestamps.
► The read timestamp of a data item holds the largest (that is, the
most recent) timestamp of those transactions that read the data
item.
► The write timestamp of a data item holds the timestamp of the
transaction that wrote the current value of the data item.
► Timestamps are used to ensure that transactions access each
data item in order of the transactions’ timestamps if their
accesses conflict.
► When this is not possible, offending transactions are aborted
and restarted with a new timestamp.
Concurrency control
► One of the fundamental properties of a transaction
is isolation.
► However, the isolation property may no longer be
preserved when several transactions execute
concurrently in the database.
► To ensure concurrent execution of transactions, the
system must control the interaction among the
concurrent transactions;
► This control is achieved through one of a variety of
mechanisms called concurrency control schemes.
► the most frequently used schemes are
two-phase locking
Lock-Based Protocols
► One way to ensure isolation is to require that
data items be accessed in a mutually exclusive
manner-
► that is, while one transaction is accessing a data
item, no other transaction can modify that data
item.
► The most common method used to implement
this requirement is to allow a transaction to
access a data item only if it is currently holding a
lock on that item.
Lock-based protocols

Mainly two modes-

Shared mode
► If a transaction Ti has obtained a shared-mode lock
(denoted by S) on item Q, then Ti can read, but cannot
write on Q.

Exclusive mode
► If a transaction Ti has obtained an exclusive-mode lock
(denoted by X) on item Q, then Ti can both read and write
on Q.
Lock-compatibility matrix

• Every transaction request a lock to

the concurrency-control manager in
an appropriate mode on data item
Q, depending on the types of
operations that it will perform on Q.
• The transaction can proceed with
Lock-compatibility
the operation only after the matrix
concurrency-control manager grants
the lock to the transaction.

• The use of these two lock (shared and exclusive) modes allows
multiple transactions to read a data item but limits write
access to just one transaction at a time.
Lock-compatibility matrix

Compatibility function –
• Let A and B represent arbitrary
lock modes.
• Suppose that a transaction Ti
requests a lock of mode A on item
Q on which transaction Tj (Ti = Tj ) Lock-compatibility
currently holds a lock of mode B. matrix comp
• If transaction Ti can be granted a
An element comp(A, B)
lock on Q immediately, in spite of of the matrix has the
the presence of the mode B lock, value true if and only if
then we say mode A is compatible mode A is compatible
with mode B. with mode B.
Lock-compatibility matrix

► Note that shared mode is compatible with shared mode, but not
with exclusive mode.
► At any time, several shared-mode locks can be held
simultaneously (by diffèrent transactions) on a particular data
item.
► A subséquent exclusive-mode lock request has to wait until the
currently held shared-mode locks are released.
► A transaction requests a shared lock on data item Q by executing
the lock- S(Q) instruction.
► Similarly, a transaction requests an exclusive lock through the
lock-X(Q) instruction.
► A transaction can unlock a data item Q by the unlock(Q)
instruction.
Locking Protocol
► Each transaction in the system follow a set of rules, called a
locking protocol, indicating when a transaction may lock and
unlock each of the data items.
► Locking protocols restrict the number of possible schedules.
► The set of all such schedules is a proper subset of all possible
serializable schedules.
► We shall present several locking protocols that allow only
conflict-serializable schedules, and thereby ensure isolation.
► When a transaction requests a lock on a data item in a
particular mode, and no other transaction has a lock on the
same data item in a conflicting mode, the lock can be granted.
Starvation condition

► Suppose a transaction T2 has a shared-mode lock on a data item,

and another transaction T1 requests an exclusive-mode lock on
the data item.
► Clearly, T1 has to wait for T2 to release the shared-mode lock.
► Meanwhile, a transaction T3 may request a shared-mode lock on
the same data item.
► The lock request is compatible with the lock granted to T2, so T3
may be granted the shared-mode lock.
► At this point T2 may release the lock, but still T1 has to wait for T3
to finish.
► But again, there may be a new transaction T4 that requests a
shared-mode lock on the same data item, and is granted the lock
before T3 releases it.
► Transaction T1 may never make progress, and is said to be
starved.
Avoid Starvation
► We can avoid starvation of transactions by granting
locks in the following manner:
► When a transaction Ti requests a lock on a data
item Q in a particular mode M, the concurrency-
control manager grants the lock provided that:
1. There is no other transaction holding a lock on Q in
a mode that conflicts with M.
2. There is no other transaction that is waiting for a
lock on Q and that made its lock request before Ti .
Two phase locking protocol
► One protocol that ensures serializability is the two-
phase locking protocol. This protocol requires that
each transaction issue lock and unlock requests in two
phases:
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 point in the schedule where the transaction has
obtained its final lock (the end of its growing phase) is
called the lock point of the transaction
Strict two-phase locking protocol.
► Cascading rollbacks can be avoided by a
modification of two-phase locking called the strict
two-phase locking protocol.
► This protocol requires not only that locking be two
phase, but also that all exclusive-mode locks taken
by a transaction be held until that transaction
commits.
► This requirement ensures that any data written by
an uncommitted transaction are locked in exclusive
mode until the transaction commits, preventing
any other transaction from reading the data.
► Another variant of two-phase locking is the
rigorous two-phase locking protocol, which
requires that all locks be held until the
transaction commits.
Time stamp based protocol

►Each transaction Ti gets time stamp

TS(Ti) from system just before execution
►It tells the order when a transaction
enters into the system.
►A transaction Tj, later will have new
Time Stamp. TS(Ti) < TS(Tj)
► Time Stamp can be implemented using
1.System Clock
2.Logical Counter

► Two Time Stamps

R-TS(Q) – Largest read time stamp (largest
timestamp of any transaction which
performed the read operation successfully)
W-TS(Q) – Largest Write time stamp (largest
timestamp of any transaction which
performed the write operation successfully)
 Timestamp-ordering protocol
Time stamp ordering protocol ensure that any conflicting read and
write operations are executed in timestamp order.
1. Suppose that transaction Ti issues Read(Q)
a. if W-TS(Q)>TS(Ti), Read operation is rejected and Ti is rolled
back.
b. otherwise execute Read operation
set R-TS(Q) = Max{R-TS(Q), TS(Ti)}
2. Suppose that transaction Ti issues Write(Q)
a. if R-TS(Q) >TS(Ti) then reject Write and Ti is rolled back.
b. if W-TS(Q) >TS(Ti) then reject Write and Ti is rolled back.
c. Execute Write(Q) operation
Timestamp-ordering protocol

► If a transaction Ti is rolled back by the concurrency-

control scheme as result of issuance of either a
read or write operation, the system assigns it a
new timestamp and restarts it.
► The timestamp-ordering protocol ensures conflict
serializability
 Timestamp-ordering protocol

• We shall assume that a

transaction is assigned
a timestamp
immediately before its
first instruction.
• Thus, in the example,
TS(T25)< TS(T26),
Example - Timestamp-ordering protocol
Validation-Based Protocols

► In cases where a majority of transactions are read-only

transactions, the rate of conflicts among transactions
may be low.
► Thus, many of these transactions, if executed without
the supervision of a concurrency-control scheme,
would nevertheless leave the system in a consistent
state.
► A concurrency-control scheme imposes overhead of
code execution and possible delay of transactions.
 Validation based protocol (optimistic)
► Use monitoring scheme-
► The validation protocol requires that each transaction Ti
executes in two or three different phases in its lifetime,
depending on whether it is a read-only or an update
transaction. The phases are, in order:
► Read Phase –
► During this phase, the system executes transaction Ti.
It reads the values of the various data items and
stores them in variables local to Ti. It performs all
write operations on temporary local variables, without
updates of the actual database.
Validation based protocol (continued)

► Validation Phase –
► The validation test is applied to transaction Ti .
This determines whether Ti is allowed to
proceed to the write phase without causing a
violation of serializability. If a transaction fails
the validation test, the system aborts the
transaction.
► Write Phase – If the validation test succeeds for
transaction Ti, the temporary local variables that hold the
results of any write operations performed by Ti are copied
to the database. Read-only transactions omit this phase.
► To perform validation we must know phases of
transaction, hence associate TimeStamp with
transaction Ti

► Start(Ti) - transaction started

► Validation(Ti) – finished read phase and started
validation phase
► Finish(Ti) – finish write phase
 Deadlock Handling

A system is said to be in deadlock state, if

every transaction is waiting for other
transaction to unlock the database.
► Deadlocks can be described precisely in terms of
a directed graph called a wait-for graph.
► This graph consists of a pair G = (V, E), where V is
a set of vertices and E is a set of edges.
 Deadlock detection - wait for graph
G(V,E)
► V is set of transactions
► Each element in the set E of edges is an ordered
pair Ti → Tj.
Ti 🡪 Tj indicates Ti waiting for Tj to unlock the
data that Ti needs.
Wait-for graph with no cycle
Wait-for graph with a cycle.
Wait for graph wait for graph
– no deadlock – deadlock
 Methods for dealing with deadlock

1. Deadlock Detection and Recovery

2. Deadlock prevention
► Prevention is commonly used if the probability that
the system would enter a deadlock state is relatively
high; otherwise, detection and recovery are more
efficient.
Deadlock prevention

Two different deadlock-prevention schemes using timestamps

have been proposed:
1. The wait–die scheme – a non-preemptive technique.
► When transaction Ti requests a data item currently held by
Tj , Ti is allowed to wait only if it has a timestamp smaller
than that of Tj (that is, Ti is older than Tj ). Otherwise, Ti is
rolled back (dies).
► For example, suppose that transactions T14, T15, and T16 have
timestamps 5, 10, and 15, respectively. If T14 requests a
data item held by T15, then T14 will wait. If T16 requests a
data item held by T15, then T16 will be rolled back.
Deadlock prevention

2. The wound–wait scheme- a preemptive

technique.
► It is a counterpart to the wait–die scheme.
► When transaction Ti requests a data item currently held by
Tj , Ti is allowed to wait only if it has a timestamp larger than
that of Tj (that is, Ti is younger than Tj ). Otherwise, Tj is
rolled back (Tj is wounded by Ti ).
► With transactions T14, T15, and T16, if T14 requests a data
item held by T15, then the data item will be preempted from
T15, and T15 will be rolled back. If T16 requests a data item
held by T15, then T16 will wait.
wound–wait

► In this scheme, if an older transaction requests for

a resource held by younger transaction, then older
transaction forces younger transaction to kill the
transaction and release the resource. The younger
transaction is restarted with minute delay but with
same timestamp. If the younger transaction is
requesting a resource which is held by older one,
then younger transaction is asked to wait till older
releases it.
 Recovery from Deadlock
The most common solution is to roll back one or more transactions to break the
deadlock. Three actions need to be taken:
1. Selection of a victim - Given a set of deadlocked transactions, we
must determine which transaction (or transactions) to roll back to
break the deadlock. We should roll back those transactions that will
incur the minimum cost.
► Many factors may determine the cost of a rollback, including:
► How long the transaction has computed, and how much
longer the transaction will compute before it completes its
designated task.
► How many data items the transaction has used.
► How many more data items the transaction needs for it to
complete.
► How many transactions will be involved in the rollback.
Recovery from Deadlock
2. Rollback. Once we have decided that a particular transaction
must be rolled back, we must determine how far this transaction
should be rolled back.
► The simplest solution is a total rollback: Abort the transaction
and then restart it.
► However, it is more effective to roll back the transaction only as
far as necessary to break the deadlock. Such partial rollback
requires the system to maintain additional information about
the state of all the running transactions.
► Specifically, the sequence of lock requests/grants and updates
performed by the transaction needs to be recorded. The
deadlock detection mechanism should decide which locks the
selected transaction needs to release in order to break the
deadlock.
Recovery from Deadlock
3. Starvation
► In a system where the selection of victims is based
primarily on cost factors, it may happen that the
same transaction is always picked as a victim.
► As a result, this transaction never completes its
designated task, thus there is starvation.
► We must ensure that a transaction can be picked
as a victim only a (small) finite number of times.