What is Concurrency Control?

Concurrency Control in Database Management System is a

procedure of managing simultaneous operations without conflicting
with each other. It ensures that Database transactions are
performed concurrently and accurately to produce correct results
without violating data integrity of the respective Database.
Concurrent access is quite easy if all users are just reading data.
There is no way they can interfere with one another. Though for any
practical Database, it would have a mix of READ and WRITE
operations and hence the concurrency is a challenge.

DBMS Concurrency Control is used to address such conflicts,

which mostly occur with a multi-user system. Therefore,
Concurrency Control is the most important element for proper
functioning of a Database Management System where two or more
database transactions are executed simultaneously, which require
access to the same data.

Potential problems of Concurrency

Here, are some issues which you will likely to face while using the
DBMS Concurrency Control method:

 Lost Updates occur when multiple transactions select the

same row and update the row based on the value selected
 Uncommitted dependency issues occur when the second
transaction selects a row which is updated by another
transaction (dirty read)
 Non-Repeatable Read occurs when a second transaction is
trying to access the same row several times and reads
different data each time.
 Incorrect Summary issue occurs when one transaction takes
summary over the value of all the instances of a repeated
data-item, and second transaction update few instances of
that specific data-item. In that situation, the resulting summary
does not reflect a correct result.

Why use Concurrency method?

MAM COLLEGE Page 1

Reasons for using Concurrency control method is DBMS:

 To apply Isolation through mutual exclusion between

conflicting transactions
 To resolve read-write and write-write conflict issues
 To preserve database consistency through constantly
preserving execution obstructions
 The system needs to control the interaction among the
concurrent transactions. This control is achieved using
concurrent-control schemes.
 Concurrency control helps to ensure serializability

Example
Assume that two people who go to electronic kiosks at the same
time to buy a movie ticket for the same movie and the same show
time.

However, there is only one seat left in for the movie show in that
particular theatre. Without concurrency control in DBMS, it is
possible that both moviegoers will end up purchasing a ticket.
However, concurrency control method does not allow this to
happen. Both moviegoers can still access information written in the
movie seating database. But concurrency control only provides a
ticket to the buyer who has completed the transaction process first.

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

MAM COLLEGE Page 2

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.

Shared/exclusive: This type of locking mechanism separates the

locks in DBMS based on their uses. If a lock is acquired on a data
item to perform a write operation, it is called an exclusive lock.

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 prevent 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 allows this transaction by placing X

MAM COLLEGE Page 3

lock on it. Therefore, when the second transaction wants to read or
write, exclusive lock prevent this operation.

3. Simplistic Lock Protocol

This type of lock-based protocols allows transactions to obtain a

lock on every object before beginning operation. Transactions may
unlock the data item after finishing the ‘write’ operation.

4. Pre-claiming Locking

Pre-claiming lock protocol helps to evaluate operations and create a

list of required data items which are needed to initiate an execution
process. In the situation when all locks are granted, the transaction
executes. After that, all locks release when all of its operations are
over.

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

Deadlock

Deadlock refers to a specific situation where two or more processes

are waiting for each other to release a resource or more than two
processes are waiting for the resource in a circular chain.

Consider the partial schedule

MAM COLLEGE Page 4

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.

• To handle a deadlock one of T3 or T4 must be rolled back and its

locks released.

The potential for deadlock exists in most locking protocols.

Deadlocks are a necessary evil.

 Starvation is also possible if concurrency control manager is

badly designed. For example:

• A transaction may be waiting for an X-lock on an item, while a

sequence of other transactions request and are granted an S-lock
on the same item.

• The same transaction is repeatedly rolled back due to deadlocks.

 Concurrency control manager can be designed to prevent

starvation.

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.
MAM COLLEGE Page 5
  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.

In the above-given diagram, you can see that local and global
deadlock detectors are searching for deadlocks and solve them with
resuming transactions to their initial states.

 Partial Schedule under Two-Phase Locking Protocol

MAM COLLEGE Page 6

Deadlock Handling

 System is deadlocked if there is a set of transactions such that

every transaction in the set is waiting for another transaction in the
set.

Deadlock Prevention

 Deadlock Detection & Deadlock Recovery

 Deadlock prevention protocols ensure that the system will never

enter into a deadlock state.

Some prevention strategies:

• Require that each transaction locks all its data items before it
begins execution (pre-declaration).

 Hard to predict what data items need to be locked

 Poor data-item utilization (most of the time data items are idle)

• No circular waits in ordering the requests for locks.

MAM COLLEGE Page 7

• Transaction roll-back whenever the waiting for the lock is required.
• Impose partial ordering of all data items and require that a
transaction can lock data items only in the order specified by the
partial order (graph-based protocol).

 wait-die scheme — non-preemptive.

• Older transaction may wait for younger one to release data item.

• Younger transactions never wait for older ones; they are rolled
back instead.

• A transaction may die several times before acquiring a lock

 wound-wait scheme — preemptive

• Older transaction wounds (forces rollback) of younger transaction

instead of waiting for it.

• Younger transactions may wait for older ones.

• Fewer rollbacks than wait-die scheme.

 In both schemes, a rolled back transactions is restarted with its

original timestamp.

• Ensures that older transactions have precedence over newer

ones, and starvation is thus avoided.

 Timeout-Based Schemes:

• A transaction waits for a lock only for a specified amount of time.

After that, the wait times out and the transaction is rolled back.

• Ensures that deadlocks get resolved by timeout if they occur

• Simple to implement

• But may roll back transaction unnecessarily in absence of

deadlock

 Difficult to determine good value of the timeout interval.

MAM COLLEGE Page 8

• Starvation is also possible

Deadlock Detection

 Wait-for graph

• Vertices: transactions

• Edge from Ti Tj . : if Ti is waiting for a lock held in conflicting

mode byTj

 The system is in a deadlock state if and only if the wait-for graph

has a cycle.

 Invoke a deadlock-detection algorithm periodically to look for

cycles.

Deadlock Recovery

 When deadlock is detected :

• Some transaction will have to rolled back (made a victim) to break

deadlock cycle.

 Select that transaction as victim that will incur minimum cost

 How long the transaction is completed & left-over

 How many data items the transaction has used and how many
required for completion?

 How many transactions are involved in deadlock

MAM COLLEGE Page 9

• Rollback -- determine how far to roll back transaction

 Total rollback: Abort the transaction and then restart it.

 Partial rollback: Roll back victim transaction only as far as

necessary to release locks that another transaction in cycle is
waiting for

 Starvation can happen (why?)

• One solution: oldest transaction in the deadlock set is never

chosen as victim.

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.

Centralized 2PL
In Centralized 2 PL, a single site is responsible for lock
management process. It has only one lock manager for the entire
DBMS.

Primary copy 2PL

Primary copy 2PL mechanism, many lock managers are distributed
to different sites. After that, a particular lock manager is responsible
for managing the lock for a set of data items. When the primary
copy has been updated, the change is propagated to the slaves.

Distributed 2PL
In this kind of two-phase locking mechanism, Lock managers are
distributed to all sites. They are responsible for managing locks for
data at that site. If no data is replicated, it is equivalent to primary
copy 2PL. Communication costs of Distributed 2PL are quite higher
than primary copy 2PL

MAM COLLEGE Page 10

Timestamp-based Protocols
Timestamp based Protocol in DBMS is an algorithm which uses
the System Time or Logical Counter as a timestamp to serialize the
execution of concurrent transactions. The Timestamp-based
protocol ensures that every conflicting read and write operations are
executed in a timestamp order.
The older transaction is always given priority in this method. It uses
system time to determine the time stamp of the transaction. This is
the most commonly used concurrency protocol.

Lock-based protocols help you to manage the order between the

conflicting transactions when they will execute. Timestamp-based
protocols manage conflicts as soon as an operation is created.

Example:
Suppose there are there transactions T1, T2, and T3.
T1 has entered the system at time 0010
T2 has entered the system at 0020
T3 has entered the system at 0030
Priority will be given to transaction T1, then transaction T2
and lastly Transaction T3.
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.

MAM COLLEGE Page 11

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.

Characteristics of Good Concurrency

Protocol
An ideal concurrency control DBMS mechanism has the following
objectives:

 Must be resilient to site and communication failures.

 It allows the parallel execution of transactions to achieve
maximum concurrency.
 Its storage mechanisms and computational methods should
be modest to minimize overhead.
 It must enforce some constraints on the structure of atomic
actions of transactions.

MAM COLLEGE Page 12

Multi Version Concurrency Control Techniques

Concurrency control is a critical aspect of database management

systems to ensure that multiple transactions can access and modify data
without leading to inconsistencies. Traditionally, techniques like Two-
Phase Locking (2PL) and Timestamp Ordering (TO) have been used to
maintain data consistency. However, in scenarios where preserving
older versions of data is essential for historical tracking or other
purposes, Multiversion Concurrency Control techniques come into play.

Understanding Multiversion Concurrency Control

Multiversion Concurrency Control (MVCC) techniques allow databases

to maintain multiple versions or values of the same data item. This
means that when a transaction updates a data item, the old value is
retained, and the new value is stored as a new version. MVCC
techniques aim to ensure the serializability of transactions while allowing
for scenarios where reading older data versions is necessary.

Breakdown of the Multi version concurrency control (MVCC)

1. Multiple Versions: When a transaction modifies a data item,

instead of changing the item in place, it creates a new version of
that item. This means that multiple versions of a database object
can exist simultaneously.

MAM COLLEGE Page 13

 2. Reads aren’t Blocked: One of the significant advantages of
MVCC is that read operations don’t get blocked by write
operations. When a transaction reads a data item, it sees a version
of that item consistent with the last time it began a transaction or
issued a read, even if other transactions are currently modifying
that item.

3. Timestamps or Transaction IDs: Each version of a data item is

tagged with a unique identifier, typically a timestamp or a
transaction ID. This identifier determines which version of the data
item a transaction sees when it accesses that item. A transaction
will always see its own writes, even if they are uncommitted.

4. Garbage Collection: As transactions create newer versions of

data items, older versions can become obsolete. There’s typically
a background process that cleans up these old versions, a
procedure often referred to as “garbage collection.”

5. Conflict Resolution: If two transactions try to modify the same

data item concurrently, the system will need a way to resolve this.
Different systems have different methods for conflict resolution. A
common one is that the first transaction to commit will succeed,
and the other transaction will be rolled back or will need to resolve
the conflict before proceeding.

Storage Overhead Considerations

One of the primary concerns with MVCC is the increased storage

requirements. Storing multiple versions of data items consumes more
disk space. However, there are scenarios where this storage overhead
is justified. For instance, in systems requiring data recovery capabilities
or those dealing with temporal databases (tracking changes and their
timestamps), maintaining older versions is essential. In such cases, the
additional storage cost is often acceptable.

Timestamp-Based Multiversion Technique

One widely used MVCC technique is based on timestamps. In this

method, several versions (X1, X2, ..., Xk) of each data item X are

MAM COLLEGE Page 14

maintained. For each version, the system keeps track of two
timestamps:

1. read_TS(Xi): The read timestamp of version Xi, indicating the

highest timestamp of transactions that have successfully read this
version.

2. write_TS(Xi): The write timestamp of version Xi, indicating the

timestamp of the transaction that wrote this version.

When a transaction T writes a new version of X, both read_TS(Xk+1)

and write_TS(Xk+1) are set to TS(T), creating a new version Xk+1.

Enforcing Serializability

To maintain serializability, specific rules are enforced:

1. For Write Operations (write_item(X)):

o If read_TS(Xi) > TS(T) and write_TS(Xi) <= TS(T) for a

version Xi, the transaction T is aborted and rolled back.

o Otherwise, a new version Xj is created with read_TS(Xj) =

write_TS(Xj) = TS(T).

2. For Read Operations (read_item(X)):

o The system identifies the version Xi with the highest

write_TS(Xi) that is less than or equal to TS(T).

o The value of Xi is returned to the transaction T, and

read_TS(Xi) is updated if necessary.

Certify Locks

Multiversion 2PL introduces three locking modes: read, write, and

certify. This approach allows concurrent reads while a transaction holds
a write lock. However, before committing, a transaction must obtain
certify locks on all items for which it holds write locks. This ensures data
consistency and avoids conflicts.

Lock Compatibility

MAM COLLEGE Page 15

The lock compatibility table for multiversion 2PL permits concurrent
reads and single writes. Still, it mandates exclusive certify locks before
committing. While this approach prevents cascading aborts (a
transaction abort causing subsequent transactions to abort), it may lead
to deadlocks if read locks are upgraded to write locks. Deadlock
handling mechanisms must be in place to address such situations.

Multiple Granularity Locking in DBMS

The various Concurrency Control schemes have used different methods and
every individual Data item is the unit on which synchronization is performed.
A certain drawback of this technique is if a transaction Ti needs to access the
entire database, and a locking protocol is used, then Ti must lock each item
in the database. It is less efficient, it would be simpler if Ti could use a single
lock to lock the entire database. But, if it considers the second proposal, this
should not in fact overlook certain flaws in the proposed method. Suppose
another transaction just needs to access a few data items from a database,
so locking the entire database seems to be unnecessary moreover it may
cost us a loss of Concurrency, which was our primary goal in the first place.
To bargain between Efficiency and Concurrency. Use Granularity.

Granularity
It is the size of the data item allowed to lock. Now Multiple Granularity means
hierarchically breaking up the database into blocks that can be locked and can be
tracked what needs to lock and in what fashion. Such a hierarchy can be represented
graphically as a tree.
For example, consider the tree, which consists of four levels of nodes. The highest
level represents the entire database. Below it is nodes of type area; the database
consists of exactly these areas. The area has children nodes which are called files.
Every area has those files that are its child nodes. No file can span more than one
area.

Finally, each file has child nodes called records. As before, the file consists of exactly
those records that are its child nodes, and no record can be present in more than one
file. Hence, the levels starting from the top level are:
 database
 area
 file
 record

MAM COLLEGE Page 16

 Multi Granularity tree Hiererchy

Consider the above diagram for the example given, each node in the tree can be
locked individually. As in the 2-phase locking protocol, it shall use shared and
exclusive lock modes. When a transaction locks a node, in either shared or exclusive
mode, the transaction also implicitly locks all the descendants of that node in the same
lock mode. For example, if transaction Ti gets an explicit lock on file Fc in exclusive
mode, then it has an implicit lock in exclusive mode on all the records belonging to
that file. It does not need to lock the individual records of Fc explicitly. this is the
main difference between Tree-Based Locking and Hierarchical locking for multiple
granularities.

Now, with locks on files and records made simple, how does the system determine if
the root node can be locked? One possibility is for it to search the entire tree but the
solution nullifies the whole purpose of the multiple-granularity locking scheme. A
more efficient way to gain this knowledge is to introduce a new lock mode,
called Intention lock mode.
Intention Mode Lock
In addition to S and X lock modes, there are three additional lock modes with multiple
granularities:
 Intention-Shared (IS): explicit locking at a lower level of the tree but only
with shared locks.
 Intention-Exclusive (IX): explicit locking at a lower level with exclusive or
shared locks.
 Shared & Intention-Exclusive (SIX): the subtree rooted by that node is
locked explicitly in shared mode and explicit locking is being done at a
lower level with exclusive mode locks.
The compatibility matrix for these lock modes are described below:

MAM COLLEGE Page 17

 Multi Granularity tree Hierarchy

The multiple-granularity locking protocol uses the intention lock modes to

ensure serializability. It requires that a transaction Ti that attempts to lock a
node must follow these protocols:
 Transaction Ti must follow the lock-compatibility matrix.
 Transaction Ti must lock the root of the tree first, and it can lock it in any
mode.
 Transaction Ti can lock a node in S or IS mode only if Ti currently has the
parent of the node-locked in either IX or IS mode.
 Transaction Ti can lock a node in X, SIX, or IX mode only if Ti currently
has the parent of the node-locked in either IX or SIX modes.
 Transaction Ti can lock a node only if Ti has not previously unlocked any
node (i.e., Ti is two-phase).
 Transaction Ti can unlock a node only if Ti currently has none of the
children of the node-locked.
Observe that the multiple-granularity protocol requires that locks be acquired
in top-down (root-to-leaf) order, whereas locks must be released in bottom-
up (leaf to-root) order.
As an illustration of the protocol, consider the tree given above and the
transactions:
 Say transaction T1 reads record Ra2 in file Fa. Then, T1 needs to lock the
database, area A1, and Fa in IS mode (and in that order), and finally to
lock Ra2 in S mode.
 Say transaction T2 modifies record Ra9 in file Fa . Then, T2 needs to lock
the database, area A1, and file Fa (and in that order) in IX mode, and at
last to lock Ra9 in X mode.

MAM COLLEGE Page 18

 Say transaction T3 reads all the records in file Fa. Then, T3 needs to lock
the database and area A1 (and in that order) in IS mode, and at last to
lock Fa in S mode.
 Say transaction T4 reads the entire database. It can do so after locking
the database in S mode.
Note that transactions T1, T3, and T4 can access the database concurrently.
Transaction T2 can execute concurrently with T1, but not with either T3 or T4.
This protocol enhances concurrency and reduces lock overhead. Deadlock is
still possible in the multiple-granularity protocol, as it is in the two-phase
locking protocol. These can be eliminated by using certain deadlock
elimination techniques.

MAM COLLEGE Page 19