Concurrency Control

Concurrency control is a very important concept of DBMS which ensures the simultaneous
execution or manipulation of data by several processes or user without resulting in data
inconsistency.

Concurrency Control is the working concept that is required for controlling and managing the
concurrent execution of database operations and thus avoiding the inconsistencies in the
database. Thus, for maintaining the concurrency of the database, we have the concurrency
control protocols.

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:

o Lock Based Concurrency Control Protocol

o Time Stamp Concurrency Control Protocol

o Validation Based Concurrency Control Protocol

o Multi-version concurrency control

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:

o It is also known as a Read-only lock. In a shared lock, the data item can only
read by the transaction.
o 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:

o In the exclusive lock, the data item can be both reads as well as written by the
transaction.
 o This lock is exclusive, and in this lock, multiple transactions do not modify the
same data simultaneously.

There are four types of lock protocols available:

1. Simplistic lock protocol

It is the simplest way of locking the data while transaction. Simplistic lock-based protocols
allow all the transactions to get the lock on the data before insert or delete or update on it. It
will unlock the data item after completing the transaction.

2. Pre-claiming Lock Protocol

o Pre-claiming Lock Protocols evaluate the transaction to list all the data items on
which they need locks.
o Before initiating an execution of the transaction, it requests DBMS for all the lock
on all those data items.
o If all the locks are granted then this protocol allows the transaction to begin.
When the transaction is completed then it releases all the lock.
o If all the locks are not granted then this protocol allows the transaction to rolls
back and waits until all the locks are granted.
3. Two-phase locking (2PL)
o The two-phase locking protocol divides the execution phase of the transaction
into three parts.
o In the first part, when the execution of the transaction starts, it seeks permission
for the lock it requires.
o In the second part, the transaction acquires all the locks. The third phase is
started as soon as the transaction releases its first lock.
o In the third phase, the transaction cannot demand any new locks. It only releases
the acquired locks.
There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may be acquired by the
transaction, but none can be released.

Shrinking phase: In the shrinking phase, existing lock held by the transaction may be
released, but no new locks can be acquired.

In the below example, if lock conversion is allowed then the following phase can happen:

1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.

2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.

Example:
The following way shows how unlocking and locking work with 2-PL.

Transaction T1:

o Growing phase: from step 1-3

o Shrinking phase: from step 5-7

o Lock point: at 3

Transaction T2:

o Growing phase: from step 2-6

o Shrinking phase: from step 8-9

o Lock point: at 6
4. Strict Two-phase locking (Strict-2PL)
o The first phase of Strict-2PL is similar to 2PL. In the first phase, after acquiring all
the locks, the transaction continues to execute normally.
o The only difference between 2PL and strict 2PL is that Strict-2PL does not
release a lock after using it.
o Strict-2PL waits until the whole transaction to commit, and then it releases all the
locks at a time.
o Strict-2PL protocol does not have shrinking phase of lock release.

Timestamp Ordering Protocol

o 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.
o 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.
o 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.
o 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.
 o 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 and Disadvantages of TO protocol:

o TO protocol ensures serializability since the precedence graph is as follows:
 o TS protocol ensures freedom from deadlock that means no transaction ever
waits.
o But the schedule may not be recoverable and may not even be cascade- free.

Validation Based Protocol

Validation phase is also known as optimistic concurrency control technique. In the validation
based protocol, the transaction is executed in the following three phases:

1. 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 database.
2. Validation phase: In this phase, the temporary variable value will be validated against the
actual data to see if it violates the serializability.

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

Here each phase has the following different timestamps:

Start(Ti): It contains the time when Ti started its execution.

Validation (Ti): It contains the time when Ti finishes its read phase and starts its validation
phase.

Finish(Ti): It contains the time when Ti finishes its write phase.

o This protocol is used to determine the time stamp for the transaction for
serialization using the time stamp of the validation phase, as it is the actual
phase which determines if the transaction will commit or rollback.
o Hence TS(T) = validation(T).

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

in advance.
o While executing the transaction, it ensures a greater degree of concurrency and
also less number of conflicts.
o Thus it contains transactions which have less number of rollbacks.
Multi-version schemes
Multi version concurrency control (MVCC) is a database optimization technique. MVCC
creates duplicate copies of records so that data can be safely read and updated at the
same time. With MVCC, database reads and writes don't block each other, and that
greatly enhances the user experience.

Advantages of Multi-Version Concurrency Control (MVCC) in DBMS

 The reduced read-and-write necessity for database locks: The database

can support many read-and-write transactions without locking the entire
system thanks to MVCC.
 Increased Concurrency: This Enables several users to use the system at
once.
 Minimize read operation delays: By enabling concurrent read operations,
MVCC helps to cut down on read times for data.
 Accuracy and consistency: Preserves data integrity over several
concurrent transactions.

Disadvantages of Multi-Version Concurrency Control (MVCC) in DBMS

Below are some disadvantages of Multi-Version Concurrency Control in DBMS

 Overhead: Keeping track of many data versions might result in overhead.
 Garbage collecting: To get rid of outdated data versions, MVCC needs
effective garbage collecting systems.
 Increase the size of the database: Expand the capacity of the database
since MVCC generates numerous copies of the records and/or tuples.
  Complexity: Compared to more straightforward locking systems, MVCC
usage might be more difficult.

Multiple Granularities
Granularity: It is the size of data item allowed to lock.

Multiple Granularities:

o It can be defined as hierarchically breaking up the database into blocks which

can be locked.
o The Multiple Granularity protocol enhances concurrency and reduces lock
overhead.
o It maintains the track of what to lock and how to lock.

o It makes easy to decide either to lock a data item or to unlock a data item. This
type of hierarchy can be graphically represented as a tree.

For example: Consider a tree which has four levels of nodes.

o The first level or higher level shows the entire database.

o The second level represents a node of type area. The higher level database
consists of exactly these areas.
o The area consists of children nodes which are known as files. No file can be
present in more than one area.
o Finally, each file contains child nodes known as records. The file has exactly
those records that are its child nodes. No records represent in more than one file.
o Hence, the levels of the tree starting from the top level are as follows:

o Database

o Area

o File

o Record
 Recovery with Concurrent Transaction

In this example, the highest level shows the entire database. The levels below are file,
record, and fields.

Recovery with Concurrent Transactions




Concurrency control means that multiple transactions can be

executed at the same time and then the interleaved logs occur. But
there may be changes in transaction results so maintain the order of
execution of those transactions.
During recovery, it would be very difficult for the recovery system to
backtrack all the logs and then start recovering.
Recovery with concurrent transactions can be done in the following
four ways.
1. Interaction with concurrency control
2. Transaction rollback
3. Checkpoints
4. Restart recovery
Interaction with concurrency control:

In this scheme, the recovery scheme depends greatly on the

concurrency control scheme that is used. So, to rollback a failed
transaction, we must undo the updates performed by the
transaction.

Transaction rollback:

 In this scheme, we rollback a failed transaction by using the

log.
 The system scans the log backward a failed transaction, for
every log record found in the log the system restores the
data item.

Checkpoints :

 Checkpoints are a process of saving a snapshot of the

applications state so that it can restart from that point in case
of failure.
 Checkpoint is a point of time at which a record is written onto
the database form the buffers.
 Checkpoint shortens the recovery process.
 When it reaches the checkpoint, then the transaction will be
updated into the database, and till that point, the entire log file
will be removed from the file. Then the log file is updated with
the new step of transaction till the next checkpoint and so on.
  The checkpoint is used to declare the point before which the
DBMS was in the consistent state, and all the transactions were
committed.
 To ease this situation, ‘Checkpoints‘Concept is used by the
most DBMS.
 In this scheme, we used checkpoints to reduce the number of
log records that the system must scan when it recovers from a
crash.
 In a concurrent transaction processing system, we require that
the checkpoint log record be of the form <checkpoint L>,
where ‘L’ is a list of transactions active at the time of the
checkpoint.
 A fuzzy checkpoint is a checkpoint where transactions are
allowed to perform updates even while buffer blocks are being
written out.

Restart recovery :
 When the system recovers from a crash, it constructs two lists.
 The undo-list consists of transactions to be undone, and the
redo-list consists of transaction to be redone.
 The system constructs the two lists as follows: Initially, they
are both empty. The system scans the log backward, examining
each record, until it finds the first <checkpoint> record.