Concurrency Control

What is Concurrency Control ?

In a multiprogramming environment where multiple

transactions can be executed simultaneously, it is highly
important to control the concurrency of transactions.
We have concurrency control protocols to ensure atomicity,
isolation, and serializability of concurrent transactions.
 Categories of Concurrency Control

Concurrency control protocols can be divided into three categories

 Lock based protocols

 Time stamp based protocols
 Validation-Based Protocols
 Lock-based Protocols

Database systems equipped with lock-based protocols use a mechanism by

which any transaction cannot read or write data until it acquires an
appropriate lock on it.

Data items can be locked in two modes :

Exclusive (X) mode : Data item can be both read as well as
written. X-lock is requested using lock-X instruction.

Shared (S) mode : Data item can only be read. S-lock is

requested using lock-S instruction.
 Lock-based Protocols

Example of a transaction performing locking:

Transaction:
lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
 Lock-based Protocols

There are three types of lock protocols available –

 Simplistic Lock Protocol

 Pre-claiming Lock Protocol
 Two-Phase Locking
 Strict Two-Phase Locking
 Lock-based Protocols

Simplistic Lock Protocol

Simplistic lock-based protocols allow transactions to obtain a lock on every
object before a 'write' operation is performed.
Transactions may unlock the data item after completing the ‘write’
operation.
 Lock-based Protocols
Pre-claiming Lock Protocol
Pre-claiming protocols evaluate their operations and
a list of data items on which they need locks.
Before initiating an execution, the transaction requests the
system for all the locks it needs beforehand.
If all the locks are granted, the transaction executes and
releases all the locks when all its operations are over.
If all the locks are not granted, the transaction rolls back
and waits until all the locks are granted.
 Lock-based Protocols
Two-Phase Locking 2PL
This locking protocol divides the execution phase of
transaction into three parts.
In the first part, when the transaction starts
it seeks permission for the locks it requires.
The second part is where the transaction acquires all
the locks. As soon as the transaction releases its first
lock, the third phase starts. In this phase, the
transaction cannot demand any new locks; it only
releases the acquired locks.
 Lock-based Protocols

Strict Two-Phase Locking

The first phase of Strict-2PL is same as 2PL.
After acquiring all the locks in the first phase,
the transaction continues to execute
normally. But in contrast to 2PL, Strict-2PL
does not release a lock after using it. Strict-
2PL holds all the locks until the commit point
and releases all the locks at a time.
 Deadlocks
In a database, a deadlock is an unwanted situation in which two or more
transactions are waiting indefinitely for one another to give up locks.
 Deadlocks

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
 Deadlock Detections

When a transaction waits for a long time to obtain a lock, The database
management system should detect whether the transaction is involved in a
deadlock or not.
 Deadlock Detections

Wait-for-graph is one of the methods for detecting the deadlock situation.

This method is suitable for smaller database. In this method a graph is
drawn based on the transaction and their lock on the resource. If the
created has a closed loop or a cycle, then there is a deadlock.
 Deadlock Prevention

A deadlock can be prevented if the resources are allocated in such a way

that deadlock never occur. The DBMS analyses the operations whether they
can create deadlock situation or not, If they do, that transaction is never
allowed to be executed.

Deadlock prevention mechanism proposes two schemes :

 Wait-Die Scheme
 Wound Wait Scheme
 Deadlock Prevention
Wait-Die Scheme

In this scheme, If a transaction request for a resource that is locked by

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.
If the older transaction has held some resource and younger transaction
waits for the resource, then younger transaction is killed and restarted with
very minute delay with same timestamp.
This scheme allows the older transaction to wait but kills the younger one.
 Deadlock Preventions
Wound Wait Scheme

In this scheme, if an older transaction requests for a resource held by

younger transaction, then older transaction forces younger transaction to
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
by older one, then younger transaction is asked to wait till older releases it.
 Deadlock Recovery
When deadlock is detected :
Some transaction will have to rolled back 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
deadlock. Starvation happens if same transaction is always chosen
victim. Include the number of rollbacks in the cost factor to avoid
starvation
 Timestamp-based Protocols
This protocol uses either system time or logical counter as a timestamp.
Lock-based protocols manage the order between the conflicting pairs
among transactions at the time of execution, whereas timestamp-based
protocols start working as soon as a transaction is created.
Every transaction has a timestamp associated with it, and the ordering is
determined by the age of the transaction. A transaction created at a clock
time would be older than all other transactions that come after it.
In addition, every data item is given the latest read and write-timestamp.
This lets the system know when the last ‘read and write’ operation was
performed on the data item.
 Timestamp ordering Protocol

The timestamp-ordering protocol ensures serializability among transactions in their

conflicting read and write operations. This is the responsibility of the protocol system
that the conflicting pair of tasks should be executed according to the timestamp values
of the transactions.
The timestamp of transaction Ti is denoted by TS(Ti)
Read time-stamp of data-item X is denoted by R-timestamp(X).
Write time-stamp of data-item X is denoted by W-timestamp(X).
 Timestamp ordering Protocol
Timestamp ordering protocol works as follows
If a transaction Ti issues a read(X) operation
 If TS(Ti) < W-timestamp(X)
Operation rejected.
 If TS(Ti) >= W-timestamp(X)
Operation executed.
 All data-item timestamps updated.
If a transaction Ti issues a write(X) operation
 If TS(Ti) < R-timestamp(X)
Operation rejected.
 If TS(Ti) < W-timestamp(X)
Operation rejected and Ti rolled back.
 Otherwise, operation executed.
 Timestamp ordering Protocol
Advantages
The timestamp-ordering protocol guarantees serializability since all the
in the precedence graph are of the form
Time stamp protocol ensures freedom from deadlock as no transaction
ever waits

Disadvantage
The schedule may not be cascade free and may not be recoverable
 Thomas' Write Rule

This rule is modified version of Timestamp ordering protocol

This rule states if TS(Ti) < W-timestamp(X), then Ti is attempting to write an
obsolete value of X.
Instead of rolling back, the write operation of X is ignored

Allows some view-serializable schedules that are not conflict-serializable.

 Validation-based Protocols

Validation phase is also known as optimistic concurrency control technique. In the

validation based protocol, the transaction is executed in the following three phases:
Read phase: In this phase, the transaction T is read and executed. It is used to read the
value of various data items and stores them in temporary local variables. It can perform
all the write operations on temporary variables without an update to the actual
Validation phase: In this phase, the temporary variable value will be validated against
the actual data to see if it violates the serializability.
Write phase: If the validation of the transaction is validated, then the temporary results
are written to the database or system otherwise the transaction is rolled back.
Validation-based Protocol
 Validation-based Protocol

The serializability is determined during the validation process. It can't be

decided in advance.
While executing the transaction, it ensures a greater degree of
and also less number of conflicts.
Thus it contains transactions which have less number of rollbacks.