What is Concurrency Control

• Process of managing simultaneous execution of transactions in a

shared database, to
ensure the serializability of transactions, is known as concurrency
control.
• Concurrency control is the management of concurrent transaction
execution. DBMS
implement concurrency control to ensure serializability and isolation
of transaction.
Why we need Concurrency Control ?
• Simultaneous execution of transactions over a shared database can
create several data
• integrity and consistency problems:
• Lost Updates.
• Uncommitted Data.
• Inconsistent retrievals.
Concurrency Control Protocols
The concurrency control protocols ensure the atomicity, consistency,
isolation, durability and serializability of the concurrent execution of
the database transactions. Therefore, these protocols are
categorized as:
1. Lock Based Concurrency Control Protocol
2. Time Stamp Concurrency Control Protocol
3. Validation Based Concurrency Control Protocol

Lock-Based Protocol
In this type of protocol, any transaction cannot read or write data
until it acquires an appropriate lock on it. There are two types of
lock:
1. Shared lock:
• It is also known as a Read-only lock. In a shared lock, the data item
can only read by the transaction.
• It can be shared between the transactions because when the
transaction holds a lock, then it can't update the data on the data
item.
2. Exclusive lock:
In the exclusive lock, the data item can be both reads as well as
written by the transaction.
This lock is exclusive, and in this lock, multiple transactions do not
modify the same data simultaneously.
Granting of Locks
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. However, care must be
taken to avoid the following scenario. 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.
In fact, it is possible that there is a sequence of transactions that
each requests a shared-mode lock on the data item, and each
transaction releases the lock a short while after it is granted, but T1
never gets the exclusive-mode lock on the data item. The transaction
T1 may never make progress, and is said to be starved.
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 other transaction holding a lock on Q in amode
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.
Thus, a lock request will never get blocked by a lock request that is
made later.
Disadvantages of locking
• Lock management overhead.
• Deadlock detection/resolution.
• Concurrency is significantly lowered, when congested nodes are
locked.
• To allow a transaction to abort itself when mistakes occur, locks
can’t be released until the end of transaction, thus currency is
significantly lowered
• (Most Important) Conflicts are rare. (We might get better
performance by not locking, and instead checking for conflicts at
commit time.)
Timestamp Ordering Protocol
• The Timestamp Ordering Protocol is used to order the transactions
based on their Timestamps. The order of transaction is nothing but
the ascending order of the transaction creation.
• The priority of the older transaction is higher that's why it
executes first. To determine the timestamp of the transaction, this
protocol uses system time or logical counter.
• The lock-based protocol is used to manage the order between
conflicting pairs among transactions at the execution time. But
Timestamp based protocols start working as soon as a transaction is
created.
• Let's assume there are two transactions T1 and T2. Suppose the
transaction T1 has entered the system at 007 times and transaction
T2 has entered the system at 009 times. T1 has the higher priority,
so it executes first as it is entered the system first.
• The timestamp ordering protocol also maintains the timestamp of
last 'read' and 'write' operation on a data.
Basic Timestamp ordering protocol works as follows:
1. Check the following condition whenever a transaction Ti issues
a Read (X) operation:
• If W_TS(X) >TS(Ti) then the operation is rejected.
• If W_TS(X) <= TS(Ti) then the operation is executed.
• Timestamps of all the data items are updated.
2. Check the following condition whenever a transaction Ti issues
a Write(X) operation:
• If TS(Ti) < R_TS(X) then the operation is rejected.
• If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled
back otherwise the operation is executed.
Where,
TS(TI) denotes the timestamp of the transaction Ti.
R_TS(X) denotes the Read time-stamp of data-item X.
W_TS(X) denotes the Write time-stamp of data-item X.
Advantages and Disadvantages of TO protocol:
• TO protocol ensures serializability since the precedence graph is as
follows:

• TS protocol ensures freedom from deadlock that means no

transaction ever waits.
• But the schedule may not be recoverable and may not even be
cascade- free.
Deadlock
A system is in a deadlock state if there exists a set of transactions
such that every transaction in the set is waiting for another
transaction in the set. More precisely, there exists a set of waiting
transactions {T0, T1, . . ., Tn} such that T0 is waiting for a data item
that T1 holds, and T1 is waiting for a data item that T2 holds, and . .
., and Tn−1 is waiting for a data item that Tn holds, and Tn is waiting
for a data item that T0 holds. None of the transactions can make
progress in such a situation. The only remedy to this undesirable
situation is for the system to invoke some drastic action, such as
rolling back some of the transactions involved in the deadlock.
Rollback of a transaction may be partial: That is, a transaction may
be rolled back to the point where it obtained a lock whose release
resolves the deadlock.
There are two principal methods for dealing with the deadlock
problem. We can use a deadlock prevention protocol to ensure that
the system will never enter a deadlock state. Alternatively, we can
allow the system to enter a deadlock state, and then try to recover
by using a deadlock detection and deadlock recovery scheme
Deadlock Prevention
There are two approaches to deadlock prevention. One approach
ensures that no cyclic waits can occur by ordering the requests for
locks, or requiring all locks to be acquired together. The other
approach is closer to deadlock recovery, and performs transaction
rollback instead of waiting for a lock, whenever thewait could
potentially result in a deadlock.
The simplest scheme under the first approach requires that each
transaction locks all its data items before it begins execution.
Moreover, either all are locked in one step or none are locked. There
are two main disadvantages to this protocol:
(1) it is often hard to predict, before the transaction begins, what
data items need to be locked
(2) data-item utilization may be very low, since many of the data
items may be locked but unused for a long time.
Another approach for preventing deadlocks is to impose an ordering
of all data items, and to require that a transaction lock data items
only in a sequence consistent with the ordering. We have seen one
such scheme in the tree protocol, which uses a partial ordering of
data items.
A variation of this approach is to use a total order of data items, in
conjunction with two-phase locking. Once a transaction has locked a
particular item, it cannot request locks on items that precede that
item in the ordering. This scheme is easy to implement, as long as
the set of data items accessed by a transaction is known when the
transaction starts execution. There is no need to change the
underlying concurrency-control system if two-phase locking is used:
All that is needed it to ensure that locks are requested in the right
order.
The second approach for preventing deadlocks is to use preemption
and transaction rollbacks. In preemption, when a transaction T2
requests a lock that transaction T1 holds, the lock granted to T1 may
be preempted by rolling back of T1, and granting of the lock to T2. To
control the preemption, we assign a unique timestamp to each
transaction. The system uses these timestamps only to decide
whether a transaction should wait or roll back. Locking is still used
for concurrency control. If a transaction is rolled back, it retains its
old timestamp when restarted. Two different deadlockprevention
schemes using timestamps have been proposed:

1. The wait–die scheme is a nonpreemptive 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 T22, T23, and T24 have
timestamps 5, 10, and 15, respectively. If T22 requests a data
itemheld by T23, then T22 will wait. If T24 requests a data item held
by T23, then T24 will be rolled back.

2. The wound–wait scheme is 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).
Returning to our example, with transactions T22, T23, and T24, if
T22 requests a data item held by T23, then the data item will be
preempted from T23, and T23 will be rolled back. If T24 requests a
data item held by T23, then T24 will wait.

Whenever the system rolls back transactions, it is important to

ensure that there is no starvation—that is, no transaction gets rolled
back repeatedly and is never allowed
to make progress.
Deadlock Detection
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. The set of vertices
consists of all the transactions in the system. Each element in the set
E of edges is an ordered pair Ti → Tj. If Ti → Tj is in E, then there
is a directed edge from transaction Ti to Tj , implying that transaction
Ti is waiting for transaction Tj to release a data item that it needs.
When transaction Ti requests a data item currently being held by
transaction Tj , then the edge Ti → Tj is inserted in the wait-for
graph. This edge is removed only when transaction Tj is no longer
holding a data item needed by transaction Ti.
A deadlock exists in the system if and only if the wait-for graph
contains a cycle. Each transaction involved in the cycle is said to be
deadlocked. To detect deadlocks, the system needs to maintain the
wait-for graph, and periodically to invoke an algorithm that searches
for a cycle in the graph.
To illustrate these concepts, consider the wait-for graph , which
depicts the following situation:

• Transaction T25 is waiting for transactions T26 and T27.

• Transaction T27 is waiting for transaction T26.
• Transaction T26 is waiting for transaction T28.

Since the graph has no cycle, the system is not in a deadlock state.
Suppose now that transaction T28 is requesting an item held by T27.
The edge T28 → T27 is added to the wait-for graph, resulting in the
new system state . This time, the graph contains the cycle
T26 → T28 →T27 →T26
implying that transactions T26, T27, and T28 are all deadlocked.
Consequently, the question arises: When should we invoke the
detection algorithm?
The answer depends on two factors:
1. How often does a deadlock occur?
2. How many transactions will be affected by the deadlock?
If deadlocks occur frequently, then the detection algorithm should
be invoked more frequently than usual. Data items allocated to
deadlocked transactions will be unavailable to other transactions
until the deadlock can be broken. In addition, the number of cycles
in the graph may also grow. In the worst case, we would invoke the
detection algorithm every time a request for allocation could not be
granted immediately.

Recovery from Deadlock

When a detection algorithm determines that a deadlock exists, the
system must recover from the 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. Unfortunately, the term minimum cost is
not a precise one. Many factors may determine the cost of a
rollback, including
a. How long the transaction has computed, and how much longer
the transaction will compute before it completes its designated task.
b. How many data items the transaction has used.
c. How many more data items the transaction needs for it to
complete.
d. How many transactions will be involved in the rollback.

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. The
selected transaction must be rolled back to the point where it
obtained the first of these locks, undoing all actions it took after that
point. The recovery mechanism must be capable of performing such
partial rollbacks. Furthermore, the transactions must be capable of
resuming execution after a partial rollback. See the bibliographical
notes for relevant references.

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 transaction can be picked as a victim only a (small) finite
number of times. The most common solution is to include the
number of rollbacks in the cost factor.