Chapter 5

Concurrency Control Techniques

Concurrency Control in a Database Management System is a fundamental concept that ensures
multiple transactions can occur concurrently without compromising the integrity or consistency of the
database. Concurrency Control is a crucial Database Management System (DBMS) component. It
manages simultaneous operations without them conflicting with each other. The primary aim is
maintaining consistency, integrity, and isolation when multiple users or applications access the
database simultaneously.

In a multi-user database environment, it’s common for numerous users to want to access and modify
the database simultaneously. This is what we call concurrent execution. Imagine a busy library where
multiple librarians are updating book records simultaneously. Just as multiple librarians shouldn’t try
to update the same record simultaneously, database users shouldn’t interfere with each other’s
operations.

Executing transactions concurrently offers many benefits, like improved system resource utilization
and increased throughput. However, these simultaneous transactions mustn’t interfere with each other.
The ultimate goal is to ensure the database remains consistent and correct. For instance, if two people
try to book the last seat on a flight at the exact moment, the system must ensure that only one person
gets the seat.

Problems with Concurrent Execution

In a database transaction, the two main operations are READ and WRITE operations. So,
there is a need to manage these two operations in the concurrent execution of the transactions
as if these operations are not performed in an interleaved manner, and the data may become
inconsistent. So, the following problems occur with the Concurrent Execution of the
operations:
Problem 1: Lost Update Problems (W - W Conflict)
The problem occurs when two different database transactions perform the read/write
operations on the same database items in an interleaved manner (i.e., concurrent execution)
that makes the values of the items incorrect hence making the database inconsistent.

For example: Consider the below diagram where two transactions TX and TY, are
performed on the same account A where the balance of account A is $300.

1|Page
  At time t1, transaction TX reads the value of account A, i.e., $300 (only read).
 At time t2, transaction TX deducts $50 from account A that becomes $250 (only
deducted and not updated/write).
 Alternately, at time t3, transaction TY reads the value of account A that will be $300
only because TX didn't update the value yet.
 At time t4, transaction TY adds $100 to account A that becomes $400 (only added but
not updated/write).
 At time t6, transaction TX writes the value of account A that will be updated as $250
only, as TY didn't update the value yet.
 Similarly, at time t7, transaction TY writes the values of account A, so it will write as
done at time t4 that will be $400. It means the value written by TX is lost, i.e., $250 is
lost.

Hence data becomes incorrect, and database sets to inconsistent.

2. Dirty Read Problems (W-R Conflict)

The dirty read problem occurs when one transaction updates an item of the database, and
somehow the transaction fails, and before the data gets rollback, the updated database item is
accessed by another transaction. There comes the Read-Write Conflict between both
transactions.

For example:

2|Page
Consider two transactions TX and TY in the below diagram performing read/write
operations on account A where the available balance in account A is $300:

 At time t1, transaction TX reads the value of account A, i.e., $300.

 At time t2, transaction TX adds $50 to account A that becomes $350.
 At time t3, transaction TX writes the updated value in account A, i.e., $350.
 Then at time t4, transaction TY reads account A that will be read as $350.
 Then at time t5, transaction TX rollbacks due to server problem, and the value changes
back to $300 (as initially).
 But the value for account A remains $350 for transaction TY as committed, which is
the dirty read and therefore known as the Dirty Read Problem.
3. Unrepeatable Read Problem (W-R Conflict)

Also known as Inconsistent Retrievals Problem that occurs when in a transaction, two
different values are read for the same database item.

For example:

Consider two transactions, TX and TY, performing the read/write operations on account
A, having an available balance = $300. The diagram is shown below:

3|Page
  At time t1, transaction TX reads the value from account A, i.e., $300.
 At time t2, transaction TY reads the value from account A, i.e., $300.
 At time t3, transaction TY updates the value of account A by adding $100 to the
available balance, and then it becomes $400.
 At time t4, transaction TY writes the updated value, i.e., $400.
 After that, at time t5, transaction TX reads the available value of account A, and that
will be read as $400.
 It means that within the same transaction TX, it reads two different values of account
A, i.e., $ 300 initially, and after updation made by transaction TY, it reads $400. It is
an unrepeatable read and is therefore known as the Unrepeatable read problem.

Thus, in order to maintain consistency in the database and avoid such problems that take
place in concurrent execution, management is needed, and that is where the concept of
Concurrency Control comes into role.

To address these challenges, the DBMS employs concurrency control techniques. Think of it like
traffic rules. Just as traffic rules ensure vehicles don’t collide, concurrency control ensures
transactions don’t conflict.

Why is Concurrency Control Needed?

As we just discussed above about what concurrency control is, from that we can now figure out that
we need concurrency control because of the following reasons listed below:
1. Ensure Database Consistency: Without concurrency control, simultaneous transactions
could interfere with each other, leading to inconsistent database states. Proper concurrency
control ensures the database remains consistent even after numerous concurrent transactions.

4|Page
 2. Avoid Conflicting Updates: When two transactions attempt to update the same data
simultaneously, one update might overwrite the other without proper control. Concurrency
control ensures that updates don’t conflict and cause unintended data loss.
3. Prevent Dirty Reads: Without concurrency control, one transaction might read data that
another transaction is in the middle of updating (but hasn’t finalized). This can lead to
inaccurate or “dirty” reads, where the data doesn’t reflect the final, committed state.
4. Enhance System Efficiency: By managing concurrent access to the database, concurrency
control allows multiple transactions to be processed in parallel. This improves system
throughput and makes optimal use of resources.
5. Protect Transaction Atomicity: For a series of operations within a transaction, it’s crucial
that all operations succeed (commit) or none do (abort). Concurrency control ensures that
transactions are atomic and treated as a single indivisible unit, even when executed
concurrently with others.

Concurrency Control Techniques in DBMS

The various concurrency control techniques are:
1. Two-phase locking Protocol
2. Time stamp ordering Protocol
3. Multi version concurrency control
4. Validation(Optimistic) concurrency control
5. Granularity of Data Items and Multiple Granularity Locking

1. Two-phase locking Protocol

Two-phase locking (2PL) is a protocol used in database management systems to control concurrency
and ensure transactions are executed in a way that preserves the consistency of a database. It’s called
“two-phase” because, during each transaction, there are two distinct phases: the Growing phase and
the Shrinking phase.
Two phase locking is a process used to gain ownership of shared resources without creating
the possibility of deadlock. The 3 activities taking place in the two phase update algorithm
are:
 Lock Acquisition
 Modification of Data
 Release Lock(the beginning of the shrink phase)
In Two phase locking no process is ever in a state where it is holding some shared resources,
and waiting for another process to release a shared resource which it requires. This means
that deadlock cannot occur due to resource contention.

5|Page
 Breakdown of the Two-Phase Locking protocol
I. Phases:
 Growing Phase: During this phase, a transaction can obtain (acquire) any number of locks as
required but cannot release any. This phase continues until the transaction acquires all the
locks it needs and no longer requests.
 Shrinking Phase: Once the transaction releases its first lock, the Shrinking phase starts.
During this phase, the transaction can release but not acquire any more locks.
II. Lock Point: The exact moment when the transaction switches from the Growing phase to the
Shrinking phase (i.e. when it releases its first lock) is termed the lock point.
The primary purpose of the Two-Phase Locking protocol is to ensure conflict-Serializability, as the
protocol ensures a transaction does not interfere with others in ways that produce inconsistent results.

2. Time stamp ordering Protocol

The Timestamp Ordering Protocol is a concurrency control method used in database management
systems to maintain the Serializability of transactions. This method uses a timestamp for each
transaction to determine its order in relation to other transactions. Instead of using locks, it ensures
transaction order based on their timestamps.
Breakdown of the Time stamp ordering protocol
1. Read Timestamp (RTS):
 This is the latest or most recent timestamp of a transaction that has read the data item.
 Every time a data item X is read by a transaction T with timestamp TS, the RTS of X
is updated to TS if TS is more recent than the current RTS of X.
2. Write Timestamp (WTS):
 This is the latest or most recent timestamp of a transaction that has written or updated
the data item.
 Whenever a data item X is written by a transaction T with timestamp TS, the WTS of
X is updated to TS if TS is more recent than the current WTS of X.

6|Page
The timestamp ordering protocol uses these timestamps to determine whether a transaction’s request
to read or write a data item should be granted. The protocol ensures a consistent ordering of
operations based on their timestamps, preventing the formation of cycles and, therefore, deadlocks.

3. Multi version concurrency control

Multi version Concurrency Control (MVCC) is a technique used in database management systems
to handle concurrent operations without conflicts, using multiple versions of a data item. Instead of
locking the items for write operations (which can reduce concurrency and lead to bottlenecks or
deadlocks), MVCC will create a separate version of the data item being modified.

Breakdown of the Multi version concurrency control (MVCC)

I. 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.
II. 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.
III. 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.
IV. 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.”

7|Page
 V. 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.

4. Validation concurrency control

Validation (or Optimistic) Concurrency Control (VCC) is an advanced database concurrency
control technique. Instead of acquiring locks on data items, as is done in most traditional (pessimistic)
concurrency control techniques, validation concurrency control allows transactions to work on private
copies of database items and validates the transactions only at the time of commit.
The central idea behind optimistic concurrency control is that conflicts between transactions are rare,
and it’s better to let transactions run to completion and only check for conflicts at commit time.
Breakdown of Validation Concurrency Control (VCC):
1. Phases: Each transaction in VCC goes through three distinct phases:
 Read Phase: The transaction reads values from the database and makes changes to its private
copy without affecting the actual database.
 Validation Phase: Before committing, the transaction checks if the changes made to its
private copy can be safely written to the database without causing any conflicts.
 Write Phase: If validation succeeds, the transaction updates the actual database with the
changes made to its private copy.
2. Validation Criteria: During the validation phase, the system checks for potential conflicts with
other transactions. If a conflict is found, the system can either roll back the transaction or delay it
for a retry, depending on the specific strategy implemented.
5. Multiple Granularity
Granularity: It is the size of data item allowed to lock.
Multiple Granularity: It can be defined as hierarchically breaking up the database into
blocks which can be locked. The Multiple Granularity protocol enhances concurrency and
reduces lock overhead. It maintains the track of what to lock and how to lock. 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.
 The first level or higher level shows the entire database.
 The second level represents a node of type area. The higher level database consists of
exactly these areas.

8|Page
  The area consists of children nodes which are known as files. No file can be present in
more than one area.
 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.
 Hence, the levels of the tree starting from the top level are as follows:
Database ->Area ->File ->Record

In this example, the highest level shows the entire database. The levels below are file, record,
and fields. Multiple granularity locking uses two types of locks:-

I. Shared Lock: - It allows multiple transactions to read the same data simultaneously. It is
used to prevent other transactions from modifying the data while a transaction is reading
it.
II. Exclusive Lock: - It prevents any other transaction from accessing the data. It is used to
prevent other transactions from reading or modifying the data while a transaction is
writing to it.
Intention mode locks are a type of lock used in multiple granularity locking that allows
multiple transactions to acquire locks on the same resource, but with different levels of
access.
There are three types of intention mode locks in multiple granularity locking

 Intent Shared (IS) Locks:- This lock is used when a transaction needs to read a
resource but does not intend to modify it. It indicates that the transaction wants to
acquire a Shared lock on a resource.

9|Page
  Intent Exclusive (IX) Locks:- This lock is used when a transaction needs to modify a
resource but does not intend to share it. It indicates that the transaction wants to
acquire an Exclusive lock on a resource.
 Shared with Intent Exclusive (SIX) Locks:- This lock is used when a transaction
intends to acquire both Shared and Exclusive locks on a resource. It indicates that the
transaction wants to acquire an Exclusive lock on a resource after acquiring Shared
locks on other resources.

These intention mode locks are used to optimize the locking mechanism in a database by
allowing transactions to acquire locks on multiple resources in a coordinated manner. They
help prevent deadlocks and improve concurrency in a database system.

Compatibility Matrix with Intention Lock Modes: The below table describes the compatibility
matrix for these lock modes:

It uses the intention lock modes to ensure Serializability. It requires that if a transaction
attempts to lock a node, then that node must follow these protocols:
 Transaction T1 should follow the lock-compatibility matrix.
 Transaction T1 firstly locks the root of the tree. It can lock it in any mode.
 If T1 currently has the parent of the node locked in either IX or IS mode, then the
transaction T1 will lock a node in S or IS mode only.
 If T1 currently has the parent of the node locked in either IX or SIX modes, then the
transaction T1 will lock a node in X, SIX, or IX mode only.
 If T1 has not previously unlocked any node only, then the Transaction T1 can lock a
node.
 If T1 currently has none of the children of the node-locked only, then Transaction T1
will unlock a node.
Observe that in multiple-granularity, the locks are acquired in top-down order, and locks
must be released in bottom-up order.
 If transaction T1 reads record R a9 in file Fa, then transaction T1 needs to lock the
database, area A1 and file Fa in IX mode. Finally, it needs to lock Ra2 in S mode.
 If transaction T2 modifies record Ra9 in file Fa, then it can do so after locking the
database, area A1 and file Fa in IX mode. Finally, it needs to lock the Ra9 in X mode.

10 | P a g e
 If transaction T3 reads all the records in file F a, then transaction T3 needs to lock the
database, and area A in IS mode. At last, it needs to lock Fa in S mode.
 If transaction T4 reads the entire database, then T4 needs to lock the database in S
mode.

11 | P a g e