Concurrency Control Protocol

Need of Concurrency Control Protocol

To maintain the consistency of shared data access during concurrent execution.
Attempting to have maximum possible concurrency without inconsistency.

Mechanisms To Control the Concurrency:

There are two mechanisms by which we can control concurrency according to our needs.
The first mechanism is that in which the user is responsible to write the consistent
concurrent transactions and they are called Lock Based Protocols.

And the second mechanism is that in which system itself tries to detect possible
inconsistency during concurrent execution and either the inconsistency recovered or
avoided. They are called Time Stamping Protocols.

Classification of concurrency control protocol

Lock based protocols
Binary locks
Shared / exclusive locks or read / write locks
2 phase locking protocol
Basic 2pl
Conservative 2pl or static 2pl
Strict 2pl
Rigorous 2 PL
Graph Based Protocol
Timestamp based protocol
Timestamp ordering protocol
Thomas write rule
Multiple granularity protocol
Multi version protocols

What is locking?
The concurrency problems can be solved by means of concurrency control technique
called locking.
A LOCK variable ( equivalent to semaphores used in OS) is associated with each data
item which is used to identify the status of the data item ( whether the data is in use or
not).
When a transaction T intends to access the data item, it must first examines the associated
LOCK.
If no other transaction holds the LOCK, the scheduler lock the data item for T.
If another transaction T1 wants to access same data item then the transaction T1 has to
wait until T releases the lock.
Thus, at a time only one transaction can access the data item.

Vnktrmnb/DBMS Page 1
Using locks, we ensure Serializability and Recoverability but sometimes they may lead to
Deadlock.
Deadlock occurs when each transaction T in set of two or more transactions is waiting
for some item that is locked by some other transaction T' in the set.
Transaction Responsibility : Legal Transaction
To request lock before use of data item
To release lock after use of data item.
Example :
T1
L(A) // Locks the data item A
R(A) // Read data item A
W(A) // Write data item A
U(A) // Unlock data item A
L(B) // Locks the data item B

Timestamp ordering

A different approach that guarantees serializability involves using transaction timestamps

in order transaction execution for an equivalent serial schedule. Timestamp ordering is an
alternative to locking in which the problem of concurrency control can be handled by
assigning ordered timestamps to transactions.

In this Scheme :

Transaction timestamp TS (T) is a unique identifier which tells the order in which the
transaction are started. Every transaction is assigned a timestamp by Database
Administrator (DBA) such that Timestamp is unique.
Time stamps are in increasing order.

Vnktrmnb/DBMS Page 2
Hence, if transaction T1 starts before transaction T2, then TS(T1) <TS(T2). A timestamp
based scheduler orders conflicting operations according to their timestamp values. Thus if
Pi(X) and Qi(X) are two conflicting operations on data item X requested by transaction
Ti and Tj,
Pi(X) will be scheduled before Qi(X) if and only if TS(Ti) < TS(Tj).

Shared and Exclusive Locks or Read/Write Locks

Need of Shared/Read and Exclusive/Write Lock

The binary lock is too restrictive for data items because at most one transaction can hold
on a given item whether the transaction is reading or writing. To improve it we have
shared and exclusive locks in which more than one transaction can access the same item
for reading purposes.i.e. the read operations on the same item by different transactions
are not conflicting.

What are Shared and Exclusive Locks

In this types of lock, system supports two kinds of lock :

 Exclusive(or Write) Locks and

 Shared(or Read) Locks.

Shared Locks

If a transaction Ti has locked the data item A in shared mode, then a request from
another transaction Tj on A for :

 Write operation on A : Denied. Transaction Tj has to wait until transaction Ti

unlock A.
 Read operation on A : Allowed.

Example :

T
S(A)
R(A) √
W(A) ×

Vnktrmnb/DBMS Page 3
Exclusive Locks

If a transaction Ti has locked a data item a in exclusive mode then request from some
another transaction Tj for-

 Read operation on A : Denied

 Write operation on A : Denied

COMPATIBLE Table for Shared and Exclusive Locks :

What does the Compatibility Table means ?

 If a transaction has lock a data item in shared mode, then another transaction can
lock the same data item in shared mode.
 If a transaction has lock a data item in shared mode, then another transaction
cannot lock the same data item in exclusive mode.
 If a transaction has lock a data item in exclusive mode, then another transaction
cannot lock the same data item in shared mode as well as exclusive mode.

Operations Used with Shared and Exclusive Locks

1. Read_lock(A) or s(A)
2. Write_lock(A) or X(A)
3. Unlock(X) or U(A)

Vnktrmnb/DBMS Page 4
Implementation of Shared and Exclusive Locks

Shared and exclusive locks are implemented using 4 fields :

1. Data_item_name
2. LOCK
3. Number of Records and
4. Locking_transaction(s)

Again to save space, items that are not in the lock table are considered to be unlocked.
The system maintains only those records for the items that are currently locked in the
lock table.

Value of LOCK(A) : Read Locked or Write Locked

 If LOCK(A) = write-locked - The value of locking transaction is a single transaction

that holds the exclusive(write) Lock on A.
 If LOCK(A) = read-locked - The value of locking transaction is a list of one or
more transactions that hold the Shared(read) on A.

Transaction Rules for Shared and Exclusive Locks

Every transaction must obey the following rules :

1. A transaction T must issue the operation s(A) or read_lock(A) or x(A) or

write_lock(A) before any read(A) operation is performed in T.
2. A transaction T must issue the operation x(A) or write_lock(A) before
any write(A) operation is performed in T.
3. After completion of all read(A) and write(A) operations in T, a transaction T must
issue an unlock(A) operation.
4. If a transaction already holds a read (shared) lock or a write (exclusive) lock on
item A, then T will not issue an unlock(A) operation.
5. A transaction that already holds a lock on item A, is allowed to convert the lock
from one locked state to another under certain conditions.
o Upgrading the Lock by Issuing a write_lock(A) Operation or Conversion of
read_lock() to write_lock() :
 Case 1 - When Conversion Not Possible : A transaction T will not
issue a write_lock(A) operation if it already holds a read (shared)
lock or write (exclusive) lock on item A.
 Case 2 - When Conversion Possible : If T is the only transaction
holding a read lock on A at the time it issues the write_lock(A)
operation, the lock can be upgraded;
o Downgrading the Lock by Issuing a read_lock(A) or Conversion of
write_lock() to read_lock() : A transaction T downgrade from the write

Vnktrmnb/DBMS Page 5
 lock to a read lock by acquiring the write_lock(A) or x(A), then the
read_lock(A) or s(A) and then releasing the write_lock(A) or x(A).

Points About Shared and Exclusive Locking :

 Shared and Exclusive Lock results more concurrency than Binary Locking.
 Shared and Exclusive Lock may not ensure serializability i.e. Non Serializable
Schedule is possible to execute using shared and exclusive locking.

2 Phase Locking

Need of 2 Phase Locking

Binary locks or shared and exclusive locks in transaction does not guarantee serializability
of schedules on its own. For example, consider a banking transaction where the read
write locking rules are used, but we get a non serializable schedule which give incorrect
result.

To ensure the serializability, we use two phase locking.

Two Phase Locking (2PL)
In this scheme, each transaction makes lock and unlock request in 2 phases :
A Growing Phase( or An Expanding Phase or First Phase) : In this phase, new locks on
the desired data item can be acquired but none can be released.
A Shrinking Phase (or Second Phase) : In this phase, existing locks can be released but no
new locks can be acquired.

Vnktrmnb/DBMS Page 6
A 2 phase locking always results serializable schedule but it does not permit all possible
erializable schedules i.e. some serializable schedules will be prohibited by the protocol.

Strategy :

A transaction T does not allowed to request any lock if T has performed already some
unlock operation and every equivalent serial schedule is based on the order of the LOCK
point.

Question : Consider the scenario and find out weather it is in 2 phase locking or not?
Solution :

Vnktrmnb/DBMS Page 7
This technique is also called as Basic 2PL.

Points About 2 Phase Locking

Every non serializable schedule failed to execute using two phase locking.
2 phase locking always results serializable schedule.
Equivalent serial schedule is based on the order of the lock point.

Vnktrmnb/DBMS Page 8
If schedule is allowed to execute bye 2pl then schedule is conflict serializable but not vice

versa.
If schedule is not conflict serializable, then schedule is not allowed to execute by 2pl.
A schedule is allowed to execute by 2 PL , then it is always serializable.

Combining Two Phase Locking and Binary Locking

The first problem in binary locking + 2 phase locking is that it leads to deadlock. In the
given example, T1 is waiting for T2 to get B and T2 is waiting for T1 to get A. Hence
deadlock occurred.
The second problem in binary locking + 2 phase locking is that it provides less
concurrency because in binary locking, 2 or more transactions simultaneously not
allowed to perform read operation. This can easily be shown in the below figure 9.

Vnktrmnb/DBMS Page 9
The third problem(shown in fig 10) in binary locking + 2 phase locking is that the same
lock is used for read as well as write, so we are unable to differentiate whether the
transaction locks a data item for reading purpose or for writing purpose.

Combining 2 Phase Locking + Shared and Exclusive Locking

Only shared and exclusive locks may not ensure serializability i.e. non serializable
schedule is possible to execute using shared and exclusive locking. For example,

But when we combine both 2 phase locking and shared and exclusive locking, then it
always results serializable schedule and the equivalent serial schedule is based on the
order of LOCKING.

Vnktrmnb/DBMS Page 10
Problems occurred in (2 Phase Locking + Shared and Exclusive Locking)

The first problem in 2PL + S/X Locking is that however, we get a serializable schedule but
it may not free from irrecoverability. Example : The schedule in figure 11 is not
recoverable schedule. To avoid irrecoverability, the Exclusive lock is called until
commit/rollback. Hence other transaction is not allowed either to read or write.( no
dependency so no problem).

The second problem in 2PL + S/X Locking is that it is not free from deadlock. For
example

Vnktrmnb/DBMS Page 11
To recover from deadlock, deadlock prevention algo is used. But the deadlock
prevention algorithm takes more CPU time than the actual work and 99.9 % times the
algorithm returns safe. Therefore it is a wastage of precious CPU time. So
Unix/Windows/Solaris don't use deadlock prevention algorithm.

Vnktrmnb/DBMS Page 12
The third problem in 2PL + S/X Locking is that the schedule is not free from starvation.

Variations of 2 Phase Locking :

There are number of variations of 2 Phase Locking :
Basic 2PL
Conservative 2pl ( or static 2PL)
Strict 2PL
Rigorous 2PL
Basic 2PL
The technique of two phase locking describe above is known as Basic 2PL.

Conservative 2PL( or Static 2PL)

In Conservative 2PL protocol, a transaction has to lock all the items it access before the
transaction begins execution. To avoid deadlocks, we can use Conservative 2PL.
Basic 2pl + all locks required to execute the transaction should be hold before starting its
execution
Advantages of Conservative 2PL :
No possibility of deadlock.
Ensure serializability.
Drawbacks of Conservative 2PL :
Less throughput.
Less resource utilisation because it holds the resources before the transaction begins
execution.

Vnktrmnb/DBMS Page 13
Less concurrency
Prediction of all the required resources before execution is also too complex.
Irrecoverability possible since no restriction on unlock operation.
However conservative 2pl is a deadlock free protocol but it is difficult to use in practice.
Starvation is possible.
How Starvation is possible ??
Question : What if some required resource is not available at the time of holding i.e.
before the transaction begins execution?
Solution : It will unlock all other resources hold by it because they were free.
It may cause starvation. Because if at a time A is not available, another point of time B is
not available and in another point of time C is not available.

Strict 2PL
A transaction T does not release any of its exclusive(write) locks until after it commits or
aborts.
Basic 2pl + all the exclusive locks should we hold until commit / rollback.

Vnktrmnb/DBMS Page 14
Points about Strict 2PL
Strict 2PL ensures serializability and the equivalent serial schedule is based on the lock
point.

Strict 2PL also ensures strict recoverable schedule.

Strict 2PL may not free from deadlock and starvation.

Vnktrmnb/DBMS Page 15
Rigorous 2PL Protocol
Transaction does not release any of its write locks and read locks until after it commits or
aborts.
Basic 2PL + All S/X locks should be hold until commit / rollback.
Rigorous 2pl protocol ensures serializability and the equivalent serial schedule is based on
the order of COMMIT.

Example

Difference Between 2PL and Rigorous 2PL Protocol

Strict 2PL Rigorous 2PL

Equivalent serial schedule is based on the Equivalent serial schedule is based on the
lock point. order of commit.
Only exclusive locks should hold up to
Both S / X locks are to be hold.
commit / rollback.
Expressive Power of Variations of 2 Phase Locking

There is no comparison between conservative 2PL and ( Strict 2PL, Basic 2PL and
Rigorous 2PL)
Relation Between Conflict Serializable, View Serializable and 2 Phase Locking Schedules

Vnktrmnb/DBMS Page 16
Binary Locks

A binary lock can have 2 States or values

 Locked (or 1) and

 Unlocked (or 0)

We represent the current state( or value) of the lock associated with data item X as
LOCK(X).

Operations used with Binary Locking

1. lock_item : A transaction request access to an item by first issuing a lock_item(X)

operation.
o If LOCK(X) =1 or L(X) : the transaction is forced to wait.
o If LOCK(X) = 0 or U(x) : it is set to 1( the transaction locks the item) and
the transaction is a load to access item X.
2. unlock_item : After using the data item the transaction issues an operation
unlock(X), which sets the operation LOCK(X) to 0 i.e. unlocks the data item so
that X may be accessed by another transactions.

Transaction Rules for Binary Locks

Every transaction must obey the following rules :

 A transaction T must issue the lock(X) operation before any read(X) or write(X)
operations in T.
 A transaction T must issue the unlock(X) operation after all read(X) and write(X)
operations in T.
 If a transaction T already holds the lock on item X, then T will not issue a lock(X)
operation.

Vnktrmnb/DBMS Page 17
  If a transaction does not holds the lock on item X, then T will not issue an
unlock(X) operation.

Example :

Points About Binary Locking :

 A binary lock enforces mutual exclusion on the data item.

 Serializability is not ensure i.e. may not eliminate non serializable schedule.
 The binary locks are simple but restrictive and so are not used in practice.

Implementation of Binary Locks :

Binary lock is implemented using 3 fields plus a queue for transactions data waiting to
access item. The 3 fields are :

1. Data_item_name
2. LOCK
3. Locking_transaction

Vnktrmnb/DBMS Page 18
To keep track of and control access to locks, DBMS has a lock manager subsystem. Items
that are not in the lock table are considered to be unlocked. The system maintains only
those records for the items that are currently lock in the lock table.

Deadlock in Transaction

What is Deadlock and How the Deadlock is occurred?

Deadlock occurs when each transaction T in a set of 2 or more transactions is waiting for
some item that is locked by some other transaction T' in the set. Hence, each transaction
in the set is on a waiting queue, waiting for one of the other transaction in the set to
release the lock on an item.
Example :

Where the Deadlock Occurs ?

The concurrency control technique called locking may lead to deadlock.

Locking
2 Phase Locking (2PL)
2PL + Binary Locking
2PL + Shared and Exclusive Locking
However, 2 phase locking ensures serializability but it may lead to a deadlock state. The
combination of (binary lock + 2 PL) and the combination of (shared and exclusive lock +
2 PL) also may lead to a deadlock state.
Example :

Vnktrmnb/DBMS Page 19
What is Deadlock Detection and Deadlock Prevention ?

Deadlock Detection deals with deadlocks in which the system check if state of deadlock
actually exists or not whereas Deadlock Prevention Protocols are used to prevent from
deadlock.

When to Use Deadlock Detection and When to Use Deadlock Prevention?

If the transaction load is light or if the transactions are short and each transaction lock
only a few items, then we should use a deadlock detection scheme.
However, if the transaction load is quite heavy or if the transaction are long and each
transaction uses many data items, then we should use a deadlock prevention scheme.

Deadlock Detection Schemes

Wait-For-Graph (WFG)
To detect the state of deadlock, directed graph is to be constructed which is called wait-
for-graph(WFG). The nodes of WFG are labelled with active transaction names. and

Vnktrmnb/DBMS Page 20
an edge exists from Ti → Tj from node Ti to node Tj iff transaction Ti is waiting for
transaction Tj to release some lock.

For a deadlock to be occur, the WFG must have a cycle and the scheduler can detect
deadlocks by checking for cycles in the WFG.

After the detection of the deadlock, it can be prevent by aborting a transaction.

The scheduler should select the transaction among the transactions involved in the cycle
of WFG whose absorption involves minimum cost i.e. it tries to select younger
transactions( which do not made many changes).
The chosen transaction for abort is called victim transaction.

Vnktrmnb/DBMS Page 21
Point :

The algorithm for victim selection generally avoid those transactions that have been for a
long time and that have performed many updates.
Timeout Method
Timeout Method is more practical scheme for deadlock. In timeout method if a
transaction waits for a period longer than a system defined timeout period, the system
assumes that the transaction may be in deadlock state and aborts it regardless of whether
a deadlock actually exist or not.
Deadlock Prevention Protocols

Deadlock prevention protocols are used to prevent from deadlock. There are various
deadlock prevention protocols which are :

Conservative Two Phase Locking (Conservative 2PL)

Since each transaction lock all the items it needs in advance, therefore no deadlock
occurs. If any of the items cannot be obtained then none of the items are locked.
The conservative 2pl is not a practical method as it provides less concurrency and it can
leads to starvation also.

Ordering All the Items Protocol

This protocol also limits concurrency because it involves ordering all the items in the
database and making sure that the transaction that need several items will look them
according to that order.
It is also not a practical method as the programmer order system is aware of the chosen
order of the items.

No Waiting Algorithm
In No Waiting Algorithm scheme if a transaction is unable to obtain a lock it is
immediately abort it and then restarted after a certain time delay without seeing whether
a deadlock will actually occur or not.
This Algorithm can cause transactions to abort and restart needlessly.

Cautious Waiting Algorithm

To reduce the number of needless aborts and restarts, the cautious algorithm is used.
Suppose there are two transaction Ti and Tj. Ti is waiting for a data item X which is
locked by Tj.
If Tj : Blocked( waiting for some other locked data item) - Abort Ti.
If Tj : Not Blocked( not waiting for some other locked data item) - Ti is blocked and
allowed to wait.
The Cautious Waiting is Deadlock Free because no transaction will never wait for
another blocked transaction.
Deadlock Prevention Using the Concept of Timestamp Ordering [TS(T)]

Vnktrmnb/DBMS Page 22
Transaction timestamp TS(T) is a unique identifier assigned to each transaction based on
the order in which transaction are started.
Transaction timestamp TS(T)
Timestamp TS(T) is a unique identifier but not any kind of time. TS(T) can be understand
as a priority identifier in which the lesser number identifies the older transaction and the
greater number identifies the younger transaction i.e.
if T1 starts before transaction T2,
then, TS(T1) < TS(T2).
(Lesser priority) (Higher priority)
(Older Transaction) (Younger Transaction)
There are two methods for preventing deadlock using the concept of timestamp ordering
:
Wait Die
Wound Wait
Suppose there are two transaction Ti and Tj where Ti is older than Tj i.e. TS(Ti) < TS(Tj),
The following rules are followed by these schemes :
Wait die :
If transaction Ti is waiting for a data item X which is locked by Tj, then Ti is allowed to
wait.

If transaction Tj is waiting for a data item X which is locked by Ti abort Tj or rollback Tj

and restart it later with the same timestamp.

Vnktrmnb/DBMS Page 23
Wound Wait :

If transaction Ti is waiting for a data item X which is locked by Tj then abort Tj or

rollback Tj and restart it later with the same timestamp.

If transaction Tj is waiting for a data item X which is locked by Ti, then Tj is allowed to

wait.

Vnktrmnb/DBMS Page 24
Starvation in Deadlock (Livelock)

What is Starvation?
The indefinite waiting of a transaction is called as starvation.

When does Starvation Occurs?

Starvation occurs when a transaction cannot proceed for an indefinite period of time
while other transactions in the system continue normally.

Example :

 Suppose 2 transactions T1 and T2 are trying to acquire a lock on a data item X,

the scheduler grants the lock to T1.
 Before the execution of T1 is over, suppose another transaction T3 also request
unlock on data item X and when T1 unlock data item X, both T2 and T3 are
trying to acquire a lock on a data item X.
 If the scheduler now grants this lock to T3, then T2 has to wait again.
 If another 4th transaction T4 may ask for data item X and the scheduler may
deprive T2 again when T3 unlocks data item X, then T2 may have to wait again.
 Thus T2 may have to wait indefinitely although there is no deadlock. Such a
situation is called Livelock or Starvation.

Starvation generally happens when we use a Priority Queue in which a lower priority
transaction will starve due to frequently coming of higher priority transaction. It can also
occurred because of victim selection if the algorithm select the same transaction as victim
repeatedly, thus causing it to abort and never finish execution.

Solutions of Starvation

Solution 1 : Using a FCFS Queue

For avoiding the Livelock is to follow a fair scheduling policy such as First Come First
Serve (FCFS) queue in which transactions are unable to lock an item in the order in which
they originally requested the lock.

Solution 2 : Increasing Priority

Allow some transaction to have priority over others. But increasing the priority of a
transaction, it has to wait longer until a highest priority transaction comes and proceeds.

Solutions 3 : Modifying the Victim Selection Algorithm

The algorithm can use higher priority for transactions that have been aborted multiple
time to avoid this problem.

Vnktrmnb/DBMS Page 25
Solution 4 : Using wait-die and wound-wait schemes

The wait-die and wound-wait schemes can also be used avoid the problem of starvation
because they restart a transaction that has been aborted with its same original timestamp,
so the possibility that the same transaction is aborted repeatedly is slim.

Multiple Granularity Locking Protocol

Before defining Multiple Granularity - let us define what is Granularity ? Granularity is

the size of data item allowed to lock. Multiple Granularity is the hierarchically breaking
up the database into portions which are lockable and maintaining the track of what to be
lock and how much to be lock so that it can be decided very quickly either to lock a data
item or to unlock a data item.

Example of Multiple Granularity

Suppose a database is divided into files; files are divided into pages; pages are divided

into records. If there is a

need to lock a record, then a transaction can easily lock it. But if there is a need to lock a
file, the transaction have to lock firstly all the records one after another, then pages in
that file and finally the file. So, there is a need to provide a mechanism for locking the
files also which is provided by multiple granularity.

Why there is a Need to provide a Mechanism for Locking Files as well as Records ?

 If we allow a mechanism for locking records only, then to lock a file, the
transaction will have to lock all records in that file(say 10000 at one time) one
after another, which is a wastage of time.
 If we allow a mechanism for locking file only, then for a transaction to lock only
five records, it will have to lock the whole file and therefore no other
transaction will be able to use that file.

Vnktrmnb/DBMS Page 26
  So, there is a need to provide the locks for files as well as records (provided by
multiple granularity).

Now the next question which comes in mind is that :

How do we Know that Some Transaction has Lock the Record or File or Database
? Because :

 If some transaction has lock a record then it should not be allowed to lock the file
or database.
 Or if some transaction has lock a record of a file and there is a need to lock a
record of another file, then it should be allowed to lock that record.

Keeping these parameters in mind, the system should be provided with maximum
concurrency without inconsistent locking because it will lead to deadlock situation. And
these parameters or protocols are called multiple granularity protocol.

Granularity at High Level : Locking at High Level

Disadvantage of Granularity at High Level:

1. Less concurrency level

Advantage of Granularity at High Level :

1. Locking is allowed at high level

2. Less complex
3. Easy to implement

Vnktrmnb/DBMS Page 27
Granularity at Low Level : Locking at Low Level

Disadvantage of Granularity at Low Level:

1. More locks required : therefore too complex compatible table.

Advantage of Granularity at Low Level:

1. High concurrency level

In order to get advantages of both ( high level granularity + low level granularity), we
use Multiple

Vnktrmnb/DBMS Page 28
Granularity

Now consider the figure 1 : Points

1. If F1 has been locked by transaction T1 and T2 wants to access the record r6, then
it should not allowed to do so, to preserve the consistency.
2. For a low-level request (say if r1 has to be locked in exclusive mode) then we have
to check the locks only upto the height of the tree ( i.e. whether P1, F1, DB is
locked or not).

3. For a high-level request (say if F1 has to be locked in exclusive mode), we have to

thoroughly search the tree ( all descendants of that particular node) if any node is
locked or not. Concurrency control will grant the permission to lock F1 only if

Vnktrmnb/DBMS Page 29
 none of the descendant of F1 should be locked by other transactions. Example :

Can we Decrease the Complexity of Searching Process ?

To Decrease the search a little bit, we can maintain information about the file whose any
record is locked by a transaction, is maintained in lock compatible table or say some
traces must be left along the path(i.e. height of the tree). So that whenever a request of
Lock is arrived, we can check the table directly.

Vnktrmnb/DBMS Page 30
Concept of Intention Locks
S : Shared Locks/Mode
X : Exclusive Locks/Mode
IS : Intention Shared Locks/Mode
IX : Intention Exclusive Locks/Mode
SIX : Shared and Intention Locks/Mode

Shared Mode (S):

If a node is locked in shared mode, then that node and all the nodes below it are locked
in shared mode.

Exclusive mode (X):

If a node is locked in exclusive mode, then that node and all the nodes below it are
locked in exclusive mode.

Intention Shared Mode (IS):

If a node is locked in intention shared mode, then there is some node below it which is
locked in shared mode. In other words, a node n locked by transaction T in IS mode

Vnktrmnb/DBMS Page 31
means that any descendants of N can be request shared (Si) lock by transaction T.

Vnktrmnb/DBMS Page 32
Shared mode (S) and Intention Shared Mode (IS) :

Intention Exclusive Mode (IX):

If a node is locked in intention exclusive mode, then there is some node in the tree
below this node which is locked in exclusive mode. In other words, a node N locked by
transaction T in IX mode means that any descendants of N can be request shared lock /
exclusive lock by transaction T.

Vnktrmnb/DBMS Page 33
Exclusive Mode(X) and Intention Exclusive Mode(IX) :

Shared and Intention Exclusive Mode (SIX):

If a node is locked in shared and intention exclusive mode (SIX) then this node is locked
in shared mode and there is some node below it which is locked in exclusive mode by
same transaction.

Vnktrmnb/DBMS Page 34
Points in SIX mode :

Consider F1 is in SIX mode buy transaction T1 :

 If another transaction ( say T2) wants to lock (r2 : shared) in shared mode, - then
T2 is allowed to lock it.
 If another transaction ( say T2) wants to lock (r2 : shared) in exclusive mode, -
then T2 is not allowed to lock it.

Vnktrmnb/DBMS Page 35
Lock Compatibility matrix
The lock compatibility matrix grants to transaction to access a data item say N only if the
locks required by them are compatible.

The Lock Compatibility Matrix :

Vnktrmnb/DBMS Page 36
What Does the Lock Compatibility Matrix Says ?

If a transaction Ti holds a data item N in IS' mode and transaction Tj requests the data
item N in IS mode then Tj is allowed to lock it in IS mode. i.e. If Ti holds a data item N
in IS mode means that there is some node below N in the tree which is in shared mode
And Tj requests the data item N in IS mode means that Tj is requesting some node below
N in shared mode, then the request for Tj is allowed.

Guidelines or Rules for Locking

1. A node N can be locked by transaction T only if parent of N is already locked.

2. A node N can be locked by transaction T in S,IS mode only if parent of N is
already locked by IX or IS mode.

3. A node N can be locked by transaction T in X, IX, SIX mode only if parent is

already locked by IX or SIX mode by transaction T.

4. Transaction T requests for lock node N only if it has not locked any node.
5. A node N can be locked by two different transactions only if both locks are
compatible.

Vnktrmnb/DBMS Page 37
 6. A node N can be unlocked by transaction T only if none of the child is locked by
transaction T.

Strict Multilevel Granularity Protocol

The rule 7 (defined below) + rules 1 to 6 (mentioned above for locking) are included in
strict multilevel granularity. Rule 7 : Hold exclusives locks until commit.

Timestamp Ordering Protocols

In timestamp based protocols, the system itself tries to detect possible inconsistency
during concurrent execution and recovers from it or avoids it. In it, for every transaction
the system executes, the system gives the timestamp to that transaction i.e. it provides a
set of timestamps to every transaction Ti by unique timestamp( any integer value) which
is denoted by TS(Ti) where TS is timestamp of Ti.

What is TS(Ti) ??
Whenever a transaction begins to execute that is just prior to its execution it is provided
a timestamp. This timestamp may be a system related actual real time stamp which is
based on the system time or it may just be a counter.

Example :

For example, Say a particular transaction T4 starts - counter = 1

When a transaction T7 starts - counter = 2
When a transaction T3 starts - counter = 3.
Whenever we want a transaction to execute the counter is incremented by 1. It is just a
logical timing value which indicates that this transaction started before or another
transaction.

Vnktrmnb/DBMS Page 38
Therefore if we have,
TS(Ti) < TS(Tj) then it means that transaction Ti starts its execution before
Tj in the system.

 So a timestamp indicates when this transaction will starts.

 The time stamp based protocols will try to check whether the concurrent
execution may be consistent or not, or the schedule that occurs must be atleast
conflict equivalent to Ti followed by Tj to the serial schedule Ti followed by Tj.

 Conflict Operations are allowed in the Timestamp ordering schedule, but they
must have the order given by the timestamp. If they do not satisfy the order, then
Rollback of transaction may or may not be performed.

Vnktrmnb/DBMS Page 39
What are R-Timestamp(RTS) and W-Timestamp(WTS)?
For Every data item which will be shared, we have got two timestamps :

 W-Timestamp(Q) or WTS(Q) : Write-timestamp of data item Q

 R-Timestamp(Q) or RTS(Q) : Read-timestamp of data item Q

W-Timestamp(Q)

W-Timestamp(Q) denotes the largest TS or TimeStamp value of any transaction that

successfully executes Write(Q).

R-Timestamp(Q)

R-Timestamp(Q) denotes the largest TS or TimeStamp value of any transaction that

successfully executes Read(Q).

Meaning of R-Timestamp and W-Timestamp :

Suppose there is a data item Q which is shared by transactions T1,T2,T3 and T4 with the
below TimeStamps executing some read and write operations.
T1 : TS(1) = 10
T2 : TS(2) = 20
T3 : TS(3) = 30
T4 : TS(4) = 40

Vnktrmnb/DBMS Page 40
Let initially Q have no value i.e. 0. i.e.

 R-Timestamp =0 or RTS(Q) = 0 and

 W-Timestamp = 0 or WTS(Q) = 0

RTS(Q) = 0 and WTS(Q) = 0 means that no transaction has read or write the data item
Q.

When Transaction issues Read(Q) :

 Suppose T1 executes Read(Q) whose TS(T1) = 10, then we will have RTS(Q)
= 0 10.

 Then, T3 executes Read(Q) whose TS(T3) = 30, then the value of RTS(Q)
= 10 30.

 Now, if T2 executes Read(Q) whose TS(T2) = 20, then the value of RTS(Q)
will remain 30.

When Transaction issues Write(Q) :

 Suppose T1 executes Write(Q) whose TS(T1) = 10, then we will have WTS(Q)
= 0 10

 Then, T4 executes Write(Q) whose TS(T4) = 40, then the value of WTS(Q)
= 10 40.

Vnktrmnb/DBMS Page 41
How will we Utilize the Idea of R-Timestamp and W-Timestamp ?

 Suppose transaction Ti is executed which is using shared data. Whenever a read or

write is executed by transaction Ti, the concurrency control mechanisms
immediately check certain things.

o "Whenever transaction Ti starts, the concurrency control mechanism sets

the new TS(Ti) value and it stores all the TS(Ti) values and all the W-
Timestamp values and the R-Timestamp values of the required data."

 Based on this, it does some analysis (called the Timestamping Protocol) and based
on this analysis it tries to check whether there can be any inconsistency in the
behavior or whether the schedule which it executing is equivalent to the serial
schedule to the required serial schedule or not.

 And if it is not, then some corrective actions will takes place by the system itself.

Vnktrmnb/DBMS Page 42
Analysis or TSO Protocol :

When Ti issues a Read(Q) :

Suppose a transaction Ti issues Read(Q) where Q is a shared data item. Now, the TS(Ti)
value will be compared with W-Timestamp(WTS) and R-Timestamp(RTS) of Q. Let W-
Timestamp(Q) and R-Timestamp(Q) be the start timestamp of a transaction Tj i.e.
TS(Tj) = WTS(Q)
and
TS(Tj) = RTS(Q)

Case 1 : If TS(Ti) < WTS(Q) ?

 What does the statement means ? It means that there is a transaction Tj which has
written on data item Q before Ti reads it and the transaction Tj started after
transaction Ti.

o According to the condition, transaction T2 is started after transaction T1
and T2 is going to write on the data item Q which is read by T1.
o According to Timestamps defined - the serial schedule will be T1 → T2.
o But there is a
 Conflict Pair : W2(Q); R1(Q)
 Dependency : T2 → T1
o Therefore, the schedule will never ever be equivalent( atleast conflict
equivalent) to the serial schedule T1 → T2.The possible situation is
described as with the help of an example.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
reject the read. This read cannot be allowed because T1 is trying to read a data
item which has been written by transaction T2 and T2 is started after T1.
 The schedule maybe consistent but it will not be conflict serializable at all to T1
followed by T2 (T1 → T2). So in general, Ti will be Rolled Back and so this read
will be rejected.

Vnktrmnb/DBMS Page 43
How do we proceed with the transaction Ti or T1?
ROLLBACK Ti or Say T1. RESTART. i.e.
Ti or T1 is rolled back and restarted.

Example :

Case 2 : If TS(Ti) ≥ WTS(Q) ?

 What does the statement means ? It means that there is a transaction Tj which has
written on data item Q after Ti reads it and the transaction Tj started
before transaction Ti.
 The possible situation is described as with the help of an example.

Vnktrmnb/DBMS Page 44
 
o According to the condition, transaction T2 is started before transaction T1
and T2 is going to write on the data item Q which is already read by T1.
o According to Timestamps defined - the serial schedule will be T1 → T2.
o The Conflict Pair will be :
 Conflict Pair : R1(Q); W2(Q)
 Dependency : T1 → T2 as shown.
o Therefore, the schedule is conflict equivalent to the serial schedule T1 →
T2.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
allow the read by transaction Ti or say T1. and
 It sets the R-Timestamp(Q) as :

RTS(Q) = max (RTS(Q),TS(T1))

Vnktrmnb/DBMS Page 45
Why there is an equal to condition in TS(Ti) ≥ WTS(Q) ?
The reason of the equal to condition is that Ti or T1 itself may have written.

Example :

Case 3 & 4 : If TS(Ti) < RTS(Q) ? or If TS(Ti) < RTS(Q) ?

 Case 3 : What does the statement TS(Ti) < RTS(Q) means? It means that there is a
transaction Tj which reads a data item Q before Ti reads it and the transaction Tj
started after transaction Ti.
 Case 4 : What does the statement TS(Ti) > RTS(Q) means? It means that there is a
transaction Tj which reads a data item Q after Ti reads it and the transaction Tj
started before transaction Ti.
 In both cases 3 & 4, transactions Ti and Tj - both are reading. So, there will be no
conflict pair exists.
 The possible situation is described as with the help of an example.

Vnktrmnb/DBMS Page 46
 o According to Timestamps defined - the serial schedule will be T1 → T2.
o Since no Conflict Pair will exists as both transactions(T1 and T2) are reading
in both the cases 3 & 4.
o Therefore, the schedule is conflict equivalent to the serial schedule T1 →
T2.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
allow the read by transaction Ti or say T1. and
 It sets the R-Timestamp(Q) as :

RTS(Q) = max (RTS(Q),TS(T1))

Vnktrmnb/DBMS Page 47
Example for Case 4 :

Vnktrmnb/DBMS Page 48
The above Cases are summarized into the following table :
When Ti issues a READ(Q) :
Cases Meaning of the Cases Situation Diagram Solution

Tj has started after Ti Reject the READ(Q).

Case 1 : TS(Ti)
and Tj has written RollBack Ti.
< WTS(Q)
before Ti reads it RESTART.

Tj has started before Ti

Case 2 : TS(Ti)
and Tj has written after
≥ WTS(Q)
Ti reads it

READ is Allowed By
Transaction Ti.

Tj has started after Ti &

Case 3 : TS(Ti)
and Tj has read before
< RTS(Q)
Ti reads it Set (RTS(Q)) =
max(RTS(Q), TS(Ti))

Tj has started before Ti

Case 4 : TS(Ti)
and Tj has read after Ti
> RTS(Q)
reads it

Vnktrmnb/DBMS Page 49
When Ti issues a Write(Q) :

Suppose a transaction Ti issues Write(Q) where Q is a shared data item. Now, the TS(Ti)
value will be compared with W-Timestamp(WTS) and R-Timestamp(RTS) of Q. Let W-
Timestamp(Q) and R-Timestamp(Q) be the start timestamp of a transaction Tj i.e.
TS(Tj) = WTS(Q)
and
TS(Tj) = RTS(Q)

Case 1 : If TS(Ti) < RTS(Q) ?

 What does the statement means ? It means that there is a transaction Tj which
reads a data item Q before Ti writes it and the transaction Tj started after
transaction Ti.
 The possible situation is described as with the help of an example.

o According to the condition, transaction T2 is started after transaction T1

and T2 is going to read the data item Q which is write by T1.
o According to Timestamps defined - the serial schedule will be T1 → T2.
o But there is a
 Conflict Pair : R2(Q); W1(Q)
 Dependency : T2 → T1 as shown.
o Therefore, the schedule will never ever be equivalent( atleast conflict
equivalent) to the serial schedule T1 → T2.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
reject the write.
 The schedule maybe consistent but it will not be conflict serializable at all to T1
followed by T2 (T1 → T2). So in general, Ti will be Rolled Back and so this

Vnktrmnb/DBMS Page 50
 write will be rejected.

How do we proceed with the transaction Ti or T1?

ROLLBACK Ti or Say T1. RESTART. i.e.
Ti or T1 is rolled back and restarted.

Example :

Case 2 : If TS(Ti) < WTS(Q) ?

Vnktrmnb/DBMS Page 51
  What does the statement means ? It means that there is a transaction Tj which has
written on data item Q before Ti writes it and the transaction Tj started after
transaction Ti.
 The possible situation is described as with the help of an example.

o According to the condition, transaction T2 is started after transaction T1

and T2 writes on the data item Q which is again write by T1.
o According to Timestamps defined - the serial schedule will be T1 → T2.
o The Conflict Pair will be :
 Conflict Pair : W2(Q); W1(Q)
 Dependency : T2 → T1 as shown.
o Therefore, the schedule will never ever be equivalent( atleast conflict
equivalent) to the serial schedule T1 → T2.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
reject the write.
 The schedule maybe consistent but it will not be conflict serializable at all to T1
followed by T2 (T1 → T2). So in general, Ti will be Rolled Back and so this
write will be rejected.

Vnktrmnb/DBMS Page 52
Example :

Case 3 : If TS(Ti) > RTS(Q) ?

 Case 3 : What does the statement TS(Ti) > RTS(Q) means? It means that there is a
transaction Tj which reads a data item Q after Ti writes it and the transaction Tj
started before transaction Ti.
 The possible situation is described as with the help of an example.

Vnktrmnb/DBMS Page 53
 o According to the condition, transaction T2 is started before transaction T1
and T2 reads the data item Q written by T1.
o According to Timestamps defined - the serial schedule will be T1 → T2.
o The Conflict Pair will be :
 Conflict Pair : W1(Q); R2(Q)
 Dependency : T1 → T2 as shown.
o Therefore, the schedule is conflict equivalent to the serial schedule T1 →
T2.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
allow the write by transaction Ti or say T1. and
 It sets the W-Timestamp(Q) as :
 WTS(Q) = TS(T1)

Vnktrmnb/DBMS Page 54
Example :

Case 4 : If TS(Ti) > WTS(Q) ?

 Case 4 : What does the statement TS(Ti) > WTS(Q) means? It means that there is
a transaction Tj which writes a data item Q after Ti writes it and the transaction Tj
started before transaction Ti.
 The possible situation is described as with the help of an example.

o According to the condition, transaction T2 is started before transaction T1

and T2 writes the data item Q which is already written by T1.
o According to Timestamps defined - the serial schedule will be T1 → T2.
o The Conflict Pair will be :
 Conflict Pair : W1(Q); W2(Q)
 Dependency : T1 → T2 as shown.
o Therefore, the schedule is conflict equivalent to the serial schedule T1 →
T2.

What happens when concurrency control protocol mechanism detects the situation?

 The concurrency control protocol mechanism will detect the situation and it will
allow the write by transaction Ti or say T1. and
 It sets the W-Timestamp(Q) as :
 WTS(Q) = TS(T1)

Vnktrmnb/DBMS Page 55
Example :

Vnktrmnb/DBMS Page 56
The above Cases are summarized into the following table :
When Ti issues a WRITE(Q) :
Cases : Meaning of the Cases Situation Diagram Solution

Case 1 : Tj has started after Ti

TS(Ti) < and Tj has read before
RTS(Q) Ti writes it

Reject the Write(Q) by

Transaction Ti.
Rollback Ti Restart Ti.

Case 2 : Tj has started after Ti

TS(Ti) < and Tj has written
WTS(Q) before Ti writes it

Case 3 : Tj has started before Ti

TS(Ti) > and Tj has read after Ti
RTS(Q) writes it Write(Q) is Allowed By
Transaction Ti.

&

Set (WTS(Q)) = TS(Ti)

Case 4 : Tj has started before Ti
TS(Ti) > and Tj has write after
WTS(Q) Ti writes it

Vnktrmnb/DBMS Page 57
Points About Timestamp Ordering :

Timestamp Based Ordering Protocol is :

 Conflict serializable i.e. it is conflict equivalent to some serial schedule.

 It is deadlock free because timestamp ordering protocol allows rollback and restart
it after detecting a mismatched situation.

Additional Overheads as Compared to Lock Based Protocol

 Overheads of maintaining the timestamps - RTS and WTS

 Checking each transaction whenever a read or write operation is executed.
 Updating each transaction after execution of read and write operation.

Advantages over overheads :

 However, there are a lot of overhead but the advantage is the user need not to be
bother at all about what is going on.
 But in Lock Based Protocols - the overheads are of waiting and the responsibility is
of the user to write the consistent concurrent transaction.
 Most widely used protocol is timestamp ordering protocol. Timestamp ordering
protocol is a system automated protocol for concurrency control.

Thomas write rule

Thomas write rule modify or improves the Basic Timestamp Ordering Algorithm (BTSO
Algorithm).

According to Basic Timestamp Ordering Algorithm (BTSO Algorithm) :

1. When Transaction Ti issues READ Operation :

a. If TS(Ti) < WTS(Q), then
 ROLLBACK Ti.
 RESTART Ti
b. Otherwise,
 allowed to execute READ operation by transaction Ti and
 Set RTS(Q) = max(RTS(Q), TS(Ti))
2. When Transaction Ti issues WRITE Operation :
a. If TS(Ti) < RTS(Q), then
 ROLLBACK Ti.
 RESTART Ti.
b. If TS(Ti) < WTS(Q), then
 ROLLBACK Ti.
 RESTART Ti.

Vnktrmnb/DBMS Page 58
 c. Otherwise,
 Allowed to execute the WRITE operation by transaction Ti and
 Set WTS(Q) = TS(Ti)

Criteria For Modification :

Before improving the BTSO protocol, it must follow some criteria :

 The First Criteria used to maintain the consistency of the system.

 After maintaining the consistency of the system, the next criteria is to trying to see
whether we can enhance the concurrency of the mechanism.

Modification in BTSO Protocol

Let us discuss the cases one by one :

1. When Ti issues a READ (R(Q)) :

a. Case (a) : If TS(Ti) < WTS(Q) ?

 Transaction Ti must have rolled back as transaction Ti is trying to
read a data item Q which is written by transaction Tj which started
after Ti.
 If we allow this, then we have thousands of examples, in which this
case will lead to problem ( As we are not analyzing what the code
exactly is. The code may or may not have the problem.)
 So no modification can be done in this case.
b. Case (b) : If TS(Ti) >= WTS(Q) ?
 The read is allowed in the otherwise case.
 So no need of modification.

Vnktrmnb/DBMS Page 59
 2. When Ti issues a WRITE (W(Q)) :

a. Case (a) : If TS(Ti) < RTS(Q) ?

 In this case also transaction Ti must have rolled back as transaction
Ti is trying to write data item Q which is already read by a
transaction Tj.
 If we allow this, then the schedule will not be conflict serializable at
all.
b. Case (B) : TS(Ti) < WTS(Q)

 This case can be improved as :

 In this case Tj writes a data item Q which is again updated by Ti and
Tj starts after Ti.
 We cannot allow the WRITE (W1(Q)) statement because it will
never be conflict serializable.
 But the question is do we have to rollback Ti?
 In BTSO protocol we do not allow to execute the write statement
and rolled back Ti.
 The modification is done as : We do not allow to execute the write
statement by Ti but we do not rollback Ti. We just continue to
execute with Ti.
 This is because any updates made by transaction Tj ( timestamp
greater than Ti) has already written the value of Q and any updates
made by Tj will be lost.
 Therefore we must ignore the write operation of Ti because it is
already outdated and obsolete.
 This way, it prevents a rollback in this situation as late as possible
and therefore tries to reduce the amount of rollback.

Vnktrmnb/DBMS Page 60
 
c. Case (c) : The otherwise case {TS(Ti) > RTS(Q) and TS(Ti) > WTS(Q)}
 The write is allowed in the otherwise case. So no need of
modification.

Thomas's Write Rule Timestamp Ordering (TWRTSO)

Modification in case (B) when transaction Ti issues a write operation is called Thomas
write rule. It rejects fewer write operations, by modifying the checks for write operation.

Thomas's Write Rule Timestamp Ordering Protocol (TWRTSO Protocol)

1. When Transaction Ti issues READ Operation :

a. If TS(Ti) < WTS(Q), then

ROLLBACK Ti.
b. Otherwise,
 allowed to execute READ operation by transaction Ti and
 Set RTS(Q) = max(RTS(Q), TS(Ti))
2. When Transaction Ti issues WRITE Operation :
a. If TS(Ti) < RTS(Q), then

Vnktrmnb/DBMS Page 61
  ROLLBACK Ti.
b. If TS(Ti) < WTS(Q), then
 Ignore WRITE operation by Ti and
 Continue the execution of Ti.

Vnktrmnb/DBMS Page 62
 c. Otherwise,
 Allowed to execute the WRITE operation by transaction Ti and
 Set WTS(Q) = TS(Ti)

Thomas Write Rule Timestamp Ordering is :

 Deadlock Free
 Ensures Serializability (equivalent serial schedule based of the order of TS value)

Problems in Thomas Write Rule Timestamp Ordering

 Starvation may be possible.

 Irrecoverability Possible.

Strict TSO Protocol : To Avoid Irrecoverability

Concurrent schedule should be equivalent to serial schedule based on TS ordering and If

transaction Ti updates data item Q, other transaction Tj is not allowed to read or write
on data item Q (R(Q)/W(Q)) until commit(C) or rollback(R) of Ti.

Vnktrmnb/DBMS Page 63
Strict Timestamp Ordering Schedule is :

 Strict Recoverable
 Deadlock Free
 Starvation still Possible

Combining :

Basic Timestamp Ordering + Strict TSO Protocol or Thomas Write Rule Timestamp
Ordering + Strict TSO Protocol

View/Conflict Serializability and Timestamp Ordering :

Consider the following Scenario :

Vnktrmnb/DBMS Page 64
If schedule is view serializable schedule and view equivalent serial schedule is based on
timestamp value, then Thomas Write Rule Timestamp Ordering Protocol allow to
execute the schedule.

Relation between Thomas Write Rule Timestamp Ordering, Basic Timestamp Ordering,
and Strict TSO Protocol :

Vnktrmnb/DBMS Page 65