Concurrency Control Protocol
Concurrency Control Protocol
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.
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
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 Locks
If a transaction Ti has locked the data item A in shared mode, then a request from
another transaction Tj on A for :
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-
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.
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
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.
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).
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
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.
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.
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.
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.
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.
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
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
We represent the current state( or value) of the lock associated with data item X as
LOCK(X).
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 :
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
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 :
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.
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.
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.
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 :
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.
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.
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.
Vnktrmnb/DBMS Page 23
Wound Wait :
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.
Example :
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
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.
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.
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.
Suppose a database is divided into files; files are divided into pages; pages are divided
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).
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.
Vnktrmnb/DBMS Page 27
Granularity at Low Level : Locking at Low Level
In order to get advantages of both ( high level granularity + low level granularity), we
use Multiple
Vnktrmnb/DBMS Page 28
Granularity
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).
Vnktrmnb/DBMS Page 29
none of the descendant of F1 should be locked by other transactions. Example :
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
If a node is locked in shared mode, then that node and all the nodes below it are locked
in shared mode.
If a node is locked in exclusive mode, then that node and all the nodes below it are
locked in exclusive mode.
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) :
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) :
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 :
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.
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.
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.
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.
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 :
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.
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)
R-Timestamp(Q)
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.
RTS(Q) = 0 and WTS(Q) = 0 means that no transaction has read or write the data item
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.
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 ?
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 :
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)
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 :
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 :
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 : 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 :
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
READ is Allowed By
Transaction Ti.
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)
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.
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.
Example :
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.
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 : 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 : 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.
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
&
Vnktrmnb/DBMS Page 57
Points About Timestamp Ordering :
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 modify or improves the Basic Timestamp Ordering Algorithm (BTSO
Algorithm).
Vnktrmnb/DBMS Page 58
c. Otherwise,
Allowed to execute the WRITE operation by transaction Ti and
Set WTS(Q) = TS(Ti)
Vnktrmnb/DBMS Page 59
2. When Ti issues a WRITE (W(Q)) :
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.
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.
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)
Deadlock Free
Ensures Serializability (equivalent serial schedule based of the order of TS value)
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
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