Anubhav Sharma (A.P.

CSE)

CONCURRENCY CONTROL TECHNIQUES

DATABASE MANAGEMENT SYSTEMS

UNIT-V

by
Anubhav Sharma
Asstt. Professor
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
 Anubhav Sharma (A.P. CSE)

What is Concurrency Control?

Concurrency control is the procedure in DBMS for managing simultaneous operations without conflicting with each
another.
 Concurrent access is quite easy if all users are just reading data. There is no way they can interfere with one
another.
 But, it would have a mix of READ and WRITE operations and hence the concurrency is a challenge.

Concurrency control is used to address such conflicts which mostly occur with a multi-user system. It helps us to
make sure that database transactions are performed concurrently without violating the data integrity of respective
databases.
Therefore, concurrency control is a most important element for the proper functioning of a system where two or
multiple database transactions that require access to the same data, are executed simultaneously.

Concurrency-control protocols : allow concurrent schedules, but ensure that the schedules are conflict/view
serializable, and are recoverable and maybe even cascadeless.

• These protocols do not examine the precedence graph as it is being created, instead a protocol imposes a
discipline that avoids non-seralizable schedules.
• Different concurrency control protocols provide different advantages between the amount of concurrency they
allow and the amount of overhead that they impose.
 Anubhav Sharma (A.P. CSE)

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.
 Lock-Based Protocols
 Timestamp-Based Protocols
 Validation-Based Protocols
 Multiple Granularity Protocols, etc.,
 Anubhav Sharma (A.P. CSE)
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 locks:

1. Shared lock(S):
 It is also known as a Read-only lock. In a shared lock, the data item can only read by the transaction.
 It can be shared between the transactions because when the transaction holds a lock, then it will never have permission
to update data on the data item.
2. Exclusive lock(X):
 In the exclusive lock, the data item can be both reads as well as written by the transaction.
 This lock is exclusive, and in this lock, multiple transactions do not modify the same data simultaneously.

Note: Any number of transactions can hold shared locks on an item, but if any transaction holds an exclusive(X) lock on
the item no other transaction may hold any lock on the item.

Upgrade / Downgrade locks : A transaction that holds a lock on an item A is allowed under certain condition to change
the lock state from one state to another.

Upgrade: A S(A) can be upgraded to X(A) if Ti is the only transaction holding the S-lock on element A.
Downgrade: We may downgrade X(A) to S(A) when we feel that we no longer want to write on data-item A. As we were
holding X-lock on A, we need not check any conditions.
 Anubhav Sharma (A.P. CSE)
LOCK-BASED PROTOCOL:
There are four types of lock based protocols,
1. Simplistic lock protocol
2. Pre-claiming Lock Protocol
3. Two-phase locking (2PL)
4. Strict Two-phase locking (Strict-2PL)

1. Simplistic lock protocol

It is the simplest way of locking the data of a transaction. Simplistic lock-based protocols allow
transactions to obtain a lock on every object before beginning operation. Transactions may unlock the data
item after finishing the transaction (or) 'write' operation.
LOCK BASED PROTOCOLS Continued… Anubhav Sharma (A.P. CSE)

2. Pre-claiming Lock Protocol

Pre-claiming lock protocol helps to evaluate operations and creates 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
are released when all of their 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 resources in a circular chain.
LOCK BASED PROTOCOLS Continued… Anubhav Sharma (A.P. CSE)

Problem With Simple Locking…

Consider the Partial Schedule:

Deadlock – consider the above execution phase.

Now, T1 holds an Exclusive lock over B, and T2 holds a
Shared lock over A. Consider Statement 7, T2 requests for
lock on B, while in Statement 8 T1 requests lock on A. we
may notice this as it imposes a Deadlock as none can proceed
with their execution.

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. This may be avoided
if the concurrency control manager is properly designed.
LOCK BASED PROTOCOLS Continued… Anubhav Sharma (A.P. CSE)

3. Two-phase locking (2PL)

The two-phase locking protocol divides the execution phase of the transaction into three parts.
 In the first part, when the execution of the transaction starts, it seeks permission for the lock it requires.
 In the second part, the transaction acquires all the locks. The third phase is started as soon as the transaction releases
its first lock.
 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 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.

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.

Note:
• It is true that the 2PL protocol offers serializability.
• However, it does not ensure that deadlocks do not happen.
LOCK BASED PROTOCOLS Continued… Anubhav Sharma (A.P. CSE)

4. Strict Two-phase locking (Strict-2PL)

 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.
 The only difference between 2PL and strict 2PL is that Strict-2PL does not release a lock after using it.
 Strict-2PL waits until the whole transaction to commit, and then it releases all the locks at a time.
 Strict-2PL protocol does not have shrinking phase of lock release.

It does not have cascading abort as 2PL does.

TIMESTAMP BASED PROTOCOL: Anubhav Sharma (A.P. CSE)

Timestamp Ordering Protocol

 The timestamp-based algorithm uses a timestamp to serialize the execution of concurrent transactions. This protocol
ensures that every conflicting read and write operations are executed in timestamp order. The protocol uses
the System Time or Logical Count as a Timestamp.
 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.
 The timestamp ordering protocol also maintains the timestamp of last 'read' and 'write' operation on a data.

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
TIMESTAMP BASED PROTOCOL Continued… Anubhav Sharma (A.P. CSE)

 The main idea for this protocol is to order the transactions based on their Timestamps. A schedule in which the
transactions participate is then serializable and the only equivalent serial schedule permitted has the transactions
in the order of their Timestamp Values.
 Timestamp Based Algorithm must ensure that, for each items accessed by Conflicting Operations in the schedule,
the order in which the item is accessed does not violate the ordering. To ensure this, use two Timestamp Values
relating to each database item X.

W_TS(X) is the largest timestamp of any transaction that executed write(X) successfully.
R_TS(X) is the largest timestamp of any transaction that executed read(X) successfully.

Basic Timestamp Ordering

 Every transaction is issued a timestamp based on when it enters the system. Suppose, if an old transaction Ti has
timestamp TS(Ti), a new transaction Tj is assigned timestamp TS(Tj) such that TS(Ti) < TS(Tj).
 The protocol manages concurrent execution such that the timestamps determine the serializability order. The
timestamp ordering protocol ensures that any conflicting read and write operations are executed in timestamp
order.
 Whenever some Transaction T tries to issue a R_item(X) or a W_item(X), the Basic TO algorithm compares the
timestamp of T with R_TS(X) & W_TS(X) to ensure that the Timestamp order is not violated.
 This describe the Basic TO protocol in following two cases.
TIMESTAMP BASED PROTOCOL Continued… Anubhav Sharma (A.P. CSE)

Basic Timestamp ordering protocol works as follows:

1. Check the following condition whenever a transaction Ti issues a Read (X) operation:
•If W_TS(X) >TS(Ti) then the operation is rejected, Ti is rolled back.
•If W_TS(X) <= TS(Ti) then the operation is executed.
•Timestamps of all the data items are updated.
2. Check the following condition whenever a transaction Ti issues a Write(X) operation:
•If TS(Ti) < R_TS(X) then the operation is rejected, Ti is rolled back.
•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:
•TO protocol ensures serializability since the precedence graph is as follows:

Fig: Precedence Graph for TS Ordering

•TS protocol ensures freedom from deadlock that means no transaction ever waits.
•But the schedule may not be recoverable and may not even be cascade- free.
VALIDATION BASED PROTOCOL: Anubhav Sharma (A.P. CSE)

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.
• 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.
• Hence TS(T) = validation(T).
• 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 concurrency and also less number of conflicts.
• Thus it contains transactions which have less number of rollbacks.
 Anubhav Sharma (A.P. CSE)
MULTIPLE GRANULARITY PROTOCOL:
Let's start by understanding the meaning of 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.
• 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:
1.Database
2.Area
3.File
4.Record
 Anubhav Sharma (A.P. CSE)
MULTIPLE GRANULARITY PROTOCOL Continued…
 For example, if transaction T igets 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
granularity.

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

Figure – Multi Granularity tree Hierarchy

In this example, the highest level shows the entire database. The levels below are file, record, and fields.
MULTIPLE GRANULARITY PROTOCOL Continued… Anubhav Sharma (A.P. CSE)

There are three additional lock modes with multiple granularity:

Intention Mode Lock-
Intention-shared (IS): It contains explicit locking at a lower level of the tree but only with shared locks.
Intention-Exclusive (IX): It contains explicit locking at a lower level with exclusive or shared locks.
Shared & Intention-Exclusive (SIX): In this lock, the node is locked in shared mode, and some node is locked in exclusive
mode by the same transaction.
Compatibility Matrix with Intention Lock Modes: The below table describes the compatibility matrix for these lock modes:
IS-Intension Shared
IX-Intension Exclusive
S-Shared
SIX-Shared & Intension Exclusive
X-Exclusive
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.
 Anubhav Sharma (A.P. CSE)
MULTIPLE GRANULARITY PROTOCOL Continued…
Compatibility Matrix with Intention Lock Mode

Figure – Multi Granularity tree Hierarchy Example:

1. T1 reads ra2
2. T2 modifies ra2(Not allowed, rollback)
3. T2 modifies ra3
4. T3 reads all records on Fa (Not Allowed, roll back)
5. T4 reads entire DB
 Anubhav Sharma (A.P. CSE)
MULTIPLE GRANULARITY PROTOCOL Continued…
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 Ra9 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.
• If transaction T3 reads all the records in file Fa, 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.
 Anubhav Sharma (A.P. CSE)
Why we need Recovery Techniques?
Classification of failure: Storage structure:
Classification of storage structure is as explained below:
To see wherever the matter has occurred, we tend to generalize a failure
into numerous classes, as follows:

1.Volatile storage: As the name suggests, a memory board (volatile storage)

cannot survive system crashes. Volatile storage devices are placed terribly near to
the CPU; usually, they’re embedded on the chipset itself. For instance, main
memory and cache memory are samples of the memory board. They’re quick
however will store a solely little quantity of knowledge.

2.Non-volatile storage: These recollections are created to survive system crashes.

they’re immense in information storage capability, however slower in the
accessibility. Examples could include hard-disks, magnetic tapes, flash memory,
and non-volatile (battery backed up) RAM.
 Anubhav Sharma (A.P. CSE)
RECOVERY AND ATOMICITY:
When a system crashes, it may have several transactions being executed and various files opened for them to modify the data
items. Transactions are made of various operations, which are atomic in nature. But according to ACID properties of DBMS,
atomicity of transactions as a whole must be maintained, that is, either all the operations are executed or none.

When a DBMS recovers from a crash, it should maintain the following −

 It should check the states of all the transactions, which were being executed.
 A transaction may be in the middle of some operation; the DBMS must ensure the atomicity of the transaction in this case.
 It should check whether the transaction can be completed now or it needs to be rolled back.
 No transactions would be allowed to leave the DBMS in an inconsistent state.

There are two types of techniques, which can help a DBMS in recovering as well as maintaining the atomicity of a transaction,
 Maintaining the logs of each transaction, and writing them onto some stable storage before actually modifying the database.
 Maintaining shadow paging, where the changes are done on a volatile memory, and later, the actual database is updated.
LOG BASED RECOVERY: Anubhav Sharma (A.P. CSE)

 Log is a sequence of records, which maintains the records of actions performed by a transaction. It is important that the
logs are written prior to the actual modification and stored on a stable storage media, which is failsafe(it can be recovered
from there).
 If any operation is performed on the database, then it will be recorded in the log.
 But the process of storing the logs should be done before the actual transaction is applied in the database.

Log-based recovery works as follows −

 The log file is kept on a stable storage media.
 When a transaction enters the system and starts execution, it writes a log about it.
<Tn Start>
 When the transaction modifies an item X, it writes log as follows −
<Tn, X, V1, V2> Ex: <Tn, City, 'Noida', 'Bangalore' >
It reads T n has changed the value of X, from V 1 to V 2. An update log record represented as: <Ti, Xj, V1, V2> has these fields:
1.Transaction identifier: Unique Identifier of the transaction that
 When the transaction finishes, it logs − performed the write operation.
<Tn Commit> 2. Data item: Unique identifier of the data item written.
3. Old value: Value of data item prior to write.
4. New value: Value of data item after write operation.

Other type of log records are:

<Ti start>: It contains information about when a transaction Ti starts.
<Ti commit>: It contains information about when a transaction Ti
commits.
<Ti abort>: It contains information about when a transaction Ti aborts.
LOG BASED RECOVERY Continued… Anubhav Sharma (A.P. CSE)

Undo and Redo Operations –

Because all database modifications must be preceded by creation of log record, the system has available both the old value
prior to modification of data item and new value that is to be written for data item. This allows system to perform redo and
undo operations as appropriate:

• Undo: using a log record sets the data item specified in log record to old value.
• Redo: using a log record sets the data item specified in log record to new value.

 Deferred database modification

 The deferred modification technique occurs if the transaction does not modify the database until it has committed.
 All logs are written on to the stable storage and the database is updated when a transaction commits.
 Immediate database modification
 The Immediate modification technique occurs if database modification occurs while the transaction is still active.
 In this technique, the database is modified immediately after every operation. It follows an actual database modification.

Recovery using Log records:

After a system crash has occurred, the system consults the log to determine which transactions need to be redone and which need to be
undone.
• Transaction Ti needs to be undone if the log contains the record <Ti start> but does not contain either the record <Ti commit> or the
record <Ti abort>.
• Transaction Ti needs to be redone if log contains record <Ti start> and either the record <Ti commit> or the record <Ti abort>.
 Anubhav Sharma (A.P. CSE)
RECOVERY WITH CONCURRENT TRANSACTIONS:
When more than one transaction are being executed in parallel, the logs are interleaved. At the time of recovery, it would become hard for
the recovery system to backtrack all logs, and then start recovering. To ease this situation, most modern DBMS use the concept of
'checkpoints'.
Checkpoint
Keeping and maintaining logs in real time and in real environment may fill out all the memory space available in the system. As time
passes, the log file may grow too big to be handled at all. Checkpoint is a mechanism where all the previous logs are removed from the
system and stored permanently in a storage disk. Checkpoint declares a point before which the DBMS was in consistent state, and all the
transactions were committed.
Recovery
When a system with concurrent transactions crashes and recovers, it behaves in the following manner −

• The recovery system reads the logs backwards from the end to the last checkpoint.
• It maintains two lists, an undo-list and a redo-list.
• If the recovery system sees a log with <Tn, Start> and <Tn, Commit>, it puts the transaction in the redo-list.
• If the recovery system sees a log with <Tn, Start> but no commit or abort log found, it puts the transaction in undo-list.
All the transactions in the undo-list are then undone and their logs are removed. All the transactions in the redo-list and their previous logs
are removed and then redone before saving their logs.