Concurrency Control Protocols

Different concurrency control protocols offer different benefits between the amount of concurrency they
allow and the amount of overhead that they impose. Following are the Concurrency Control techniques
in DBMS:
• Lock-Based Protocols
• Two Phase Locking Protocol
• Timestamp-Based Protocols
• Validation-Based Protocols

Lock-based Protocols
Lock Based Protocols in DBMS is a mechanism in which a transaction cannot Read or Write the data
until it acquires an appropriate lock. Lock based protocols help to eliminate the concurrency problem
in DBMS for simultaneous transactions by locking or isolating a particular transaction to a single user.
A lock is a data variable which is associated with a data item. This lock signifies that operations that
can be performed on the data item. Locks in DBMS help synchronize access to the database items by
concurrent transactions.
All lock requests are made to the concurrency-control manager. Transactions proceed only once the
lock request is granted.
Binary Locks: A Binary lock on a data item can either locked or unlocked states.
1. Shared Lock (S):
A shared lock is also called a Read-only lock. With the shared lock, the data item can be shared between
transactions. This is because you will never have permission to update data on the data item.
For example, consider a case where two transactions are reading the account balance of a person.
The database will let them read by placing a shared lock. However, if another transaction wants to
update that account’s balance, shared lock prevents it until the reading process is over.
2. Exclusive Lock (X):
With the Exclusive Lock, a data item can be read as well as written. This is exclusive and can’t be held
concurrently on the same data item. X-lock is requested using lock-x instruction. Transactions may
unlock the data item after finishing the ‘write’ operation.
For example, when a transaction needs to update the account balance of a person. You can allow this
transaction by placing X lock on it. Therefore, when the second transaction wants to read or write,
exclusive lock prevents this operation.
Starvation
Starvation is the situation when a transaction needs to wait for an indefinite period to acquire a lock.
Following are the reasons for Starvation:
• When waiting scheme for locked items is not properly managed
• In the case of resource leak
• The same transaction is selected as a victim repeatedly
Consider the following two schedules of actions on the data items A, B, C and D, listed in the order it
is submitted to the DBMS (S is a shared lock, X is an exclusive lock):
S1: T4:X(A), T3:S(C), T1:S(B), T2:X(B), T3:X(C), T2:X(A), T1:S(C), T4:S(B)
S2: T1:X(A), T3:S(D), T3: S(A), T4:X(C), T2:S(B), T4:X(A), T2:X(C), T1:X(B), T4:X(D) For both
the sequences S1 and S2.
1. Mention for each request whether the request is granted or blocked by the lock manager.
Answer
A1. g is for (granted) and b is for (blocked)
For schedule S1
T4:X(A), T3:S(C), T1:S(B), T2:X(B), T3:X(C), T2:X(A), T1:S(C), T4:S(B)

T1 T2 T3 T4

X(A),g

S(C),g

S(B),g

X(B),b

X(C),g

X(A),b

S(C),b

S(B),g

Similarly for S2:

T1:X(A), T3:S(D), T3:S(A), T4:X(C), T2:S(B), T4:X(A), T2:X(C), T1:X(B), T4:X(D)

T1 T2 T3 T4

X(A),g

S(D),g

S(A),b

X(C),g

S(B),g

X(A),b

X(C),b

X(B),b

X(D),b
Two Phase Locking Protocol
Two Phase Locking Protocol also known as 2PL protocol is a method of concurrency control in DBMS
that ensures serializability by applying a lock to the transaction data which blocks other transactions to
access the same data simultaneously. Two Phase Locking protocol helps to eliminate the concurrency
problem in DBMS.
This locking protocol divides the execution phase of a transaction into three different parts.
• In the first phase, when the transaction begins to execute, it requires permission for the locks it
needs.
• The second part is where the transaction obtains all the locks. When a transaction releases its
first lock, the third phase starts.
• In this third phase, the transaction cannot demand any new locks. Instead, it only releases the
acquired locks.

The Two-Phase Locking protocol allows each transaction to make a lock or unlock request in two steps:
• Growing Phase: In this phase transaction may obtain locks but may not release any locks.
• Shrinking Phase: In this phase, a transaction may release locks but not obtain any new lock.
It is true that the 2PL protocol offers serializability. However, it does not ensure that deadlocks do not
happen.

Strict Two-Phase Locking Method

Strict-Two phase locking system is almost similar to 2PL. The only difference is that Strict-2PL never
releases a lock after using it. It holds all the locks until the commit point and releases all the locks at
one go when the process is over.

Timestamp-based Protocols
• 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:
o If W_TS(X) >TS(Ti) then the operation is rejected.
o If W_TS(X) <= TS(Ti) then the operation is executed.
o Timestamps of all the data items are updated.

2. Check the following condition whenever a transaction Ti issues a Write(X) operation:

o If TS(Ti) < R_TS(X) then the operation is rejected.
o 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:
• Schedules are serializable just like 2PL protocols.
• No waiting for the transaction, which eliminates the possibility of deadlocks.
Disadvantages:
Starvation is possible if the same transaction is restarted and continually aborted.

Validation Based Protocol

Validation based Protocol in DBMS also known as Optimistic Concurrency Control Technique is a
method to avoid concurrency in transactions. In this protocol, the local copies of the transaction data
are updated rather than the data itself, which results in less interference while execution of the
transaction.
The Validation based Protocol is performed in the following three phases:
1. Read Phase
2. Validation Phase
3. Write Phase
Read Phase
In the Read Phase, the data values from the database can be read by a transaction but the write operation
or updates are only applied to the local data copies, not the actual database.
Validation Phase
In Validation Phase, the data is checked to ensure that there is no violation of serializability while
applying the transaction updates to the database.
Write Phase
In the Write Phase, the updates are applied to the database if the validation is successful, else; the
updates are not applied, and the transaction is rolled back.

Deadlock in DBMS
A deadlock is a condition where two or more transactions are waiting indefinitely for one another to
give up locks. Deadlock is said to be one of the most feared complications in DBMS as no task ever
gets finished and is in waiting state forever.
For example: In the student table, transaction T1 holds a lock on some rows and needs to update some
rows in the grade table. Simultaneously, transaction T2 holds locks on some rows in the grade table and
needs to update the rows in the Student table held by Transaction T1.
Now, the main problem arises. Now Transaction T1 is waiting for T2 to release its lock and similarly,
transaction T2 is waiting for T1 to release its lock. All activities come to a halt state and remain at a
standstill. It will remain in a standstill until the DBMS detects the deadlock and aborts one of the
transactions.

Below is a list of conditions necessary for a deadlock to occur:

• Mutual Exclusion: Only one transaction can hold a particular resource at a time.
• Hold and Wait: The Transactions holding resources may request additional resources held by
others.
• No Preemption: The Resources cannot be forcibly taken from the transaction holding them.
• Circular Wait: A cycle of transactions exists where each transaction is waiting for the resource
held by the next transaction in the cycle.
To avoid a deadlock atleast one of the above-mentioned necessary conditions should not occur.

Deadlock Avoidance

o Deadlock avoidance in DBMS is a technique used to prevent deadlocks from occurring. This is
achieved by introducing a policy for allocating resources that avoids the conditions for a
deadlock.
 o There are two main methods for deadlock avoidance in DBMS are Resource Allocation Graph
(RAG) Algorithm and Wait-For Graph Algorithms. Both of these approaches aim to ensure that
there are no circular wait conditions in the system, which is the root cause of deadlocks.

o Deadlock avoidance is an effective technique for preventing deadlocks in a DBMS. It allows

for more efficient use of system resources and reduces the risk of system failure.

Deadlock Detection
In a database, when a transaction waits indefinitely to obtain a lock, then the DBMS should detect
whether the transaction is involved in a deadlock or not. The lock manager maintains a Wait for the
graph to detect the deadlock cycle in the database.
Wait for Graph
o This is the suitable method for deadlock detection. In this method, a graph is created based on
the transaction and their lock. If the created graph has a cycle or closed loop, then there is a
deadlock.
o The wait for the graph is maintained by the system for every transaction which is waiting for
some data held by the others. The system keeps checking the graph if there is any cycle in the
graph.
The wait for a graph for the above scenario is shown below:

Deadlock Prevention
o Deadlock prevention method is suitable for a large database. If the resources are allocated in
such a way that deadlock never occurs, then the deadlock can be prevented.
o The Database management system analyses the operations of the transaction whether they can
create a deadlock situation or not. If they do, then the DBMS never allowed that transaction to
be executed.
Each transaction has unique identifier which is called timestamp. It is usually based on the state of the
transaction and assigned once the transaction is started. For example, if the transaction T1 starts before
the transaction T2 then the timestamp corresponding to the transaction T1 will be less than timestamp
corresponding to transaction T2. The timestamp decides whether a transaction should wait or abort and
rollback. Aborted transaction retains their timestamps values and hence the seniority.
The following deadlock prevention schemes using timestamps have been proposed.
o Wait-Die scheme
o Wound wait scheme
The significant disadvantage of both of these techniques is that some transactions are aborted and
restarted unnecessarily even though those transactions never actually cause a deadlock.
Wait-Die scheme
In this scheme, if a transaction requests a resource that is locked by another transaction, then the
DBMS simply checks the timestamp of both transactions and allows the older transaction to wait until
the resource is available for execution.

Checks if TS (T1) < TS (T2) – if T1 is the older transaction and T2 has held some resource, then it
allows T1 to wait until resource is available for execution. That means if a younger transaction has
locked some resource and an older transaction is waiting for it, then an older transaction is allowed to
wait for it till it is available. If T1 is an older transaction and has held some resource with it and if T2 is
waiting for it, then T2 is killed and restarted later with random delay but with the same timestamp. i.e.
if the older transaction has held some resource and the younger transaction waits for the resource, then
the younger transaction is killed and restarted with a very minute delay with the same timestamp.
This scheme allows the older transaction to wait but kills the younger one.

Wound-wait scheme
In this scheme, if an older transaction requests for a resource held by a younger transaction, then an
older transaction forces a younger transaction to kill the transaction and release the resource. The
younger transaction is restarted with a minute delay but with the same timestamp. If the younger
transaction is requesting a resource that is held by an older one, then the younger transaction is asked
to wait till the older one releases it.
In general, the Wait-Die algorithm is used when data consistency is a high priority, and the Wound-Wait
algorithm is used when data availability is a high priority.

Recovery from Deadlock

If the wait for graph which is used for deadlock detection contains a deadlock situation i.e. there exists
cycles in it then those cycles should be removed to recover from the deadlock. The most widely used
technique of recovering from a deadlock is to rollback one or more transactions till the system no longer
displays a deadlock condition.
The selection of the transactions to be rolled back is based on the following deliberations:
Selection of victim: There may be many transactions which are involved in a deadlock i..e deadlocked
transaction. So, to recover from the deadlock some of the transaction should be rolled back, out of the
possible transactions causing a deadlock. The one that is rolled back is known as victim transaction and
the mechanism is known as victim election.
Rollback: Once the selection of the transaction to be rolled back is decided we should find out how far
the current transaction should be rolled back. One of the simplest solutions is the total rollback i.e. abort
the transaction and restart it. However, the transaction should be rolled back to the extent required to
break the deadlock. Also, the additional information of the state of currently executing transactions
should be maintained.
Starvation: To recover from the deadlock, we must ensure that the same transaction should not be
selected again and again as a victim to rollback. The transaction will never complete if the type of
situation is not avoided. To avoid starvation, only a finite number of times a transaction should be picked
up as a victim.
A widely used solution is to include the number of rollbacks of the transaction that is selected as the
victim.