Transaction Management & Concurrency Control
T1
T2
Concurrency
Control
Manager
T3
T4
Concurrency
Control
Manager
lock-X(B)
lock-X(B)
grant-X(B,T3)
grant-X(B,T1)
read (B)
read (B)
B:=B-50
B:=B-50
write(B)
write(B)
unlock(B)
lock-X(A)
lock-S(A)
grant-X(A,T3)
grant-S(A,T2)
read(A)
read(A)
A:=A+50
unlock(A)
write(A)
lock-S(B)
grant-S(B,T2)
unlock (B)
unlock (A)
read (B)
lock-S(A)
unlock (B)
read(A)
Display(A+B)
grant-S(A,T4)
unlock(A)
lock-X(A)
grant-X(A,T1)
lock-S(B)
grant-S(B,T4)
read(A)
read(B)
A:=A+50
unlock(B)
write(A)
Display(A+B)
unlock(A)
Schedule 1
Schedule 2
Transaction T3 - Transaction T1 with unlocking delayed.
Transaction T4 – Transaction T2 with unlocking delayed.
Schedule 3 - Deadlock
T3
T4
Concurrency
Control
Manager
lock-X(B)
•
System must roll back one of the two transactions.
•
Data item locked by that transaction are unlocked.
•
If data is unlocked immediately after reading or
writing - may be inconsistent state.
grant-X(B,T3)
* If data is not unlocked before requesting a lock by
read (B)
another transaction - may be deadlock.
B:=B-50
write(B)
lock-S(A)
grant-S(A,T4)
read (A)
lock-S(B)
wait for T3
lock – X(A)
wait for T4
Transaction must follow the locking protocol.
When a transaction may lock or unlock each data item.
Locking protocol restrict the no. of possible schedules.
Set of all such schedules is a proper subset of all possible serializable schedules.
{T0 , T1 , T2 ….. Tn } be a set of transactions participating in a schedule S.
Ti precedes T j
Ti
Tj in S when
Data item Q on which Ti holding lock of mode A
T j later require lock mode B on data item Q .
If comp(A,B) = false.
Ti must appear before T j.
•
Transaction T2 has a shared mode lock on a data item.
•
Transaction T1 requests an exclusive mode lock for same data item .
•
T1 has to wait for T2 to release shared mode lock.
•
Same time transaction T3 may request shared mode lock on same data item.
•
Lock request is compatible.
•
T3 may be granted a shared mode lock.
•
Now T1 has to wait for T3 to release shared mode lock though T2 has released a lock.
•
Again there may be a transaction T4 requesting a shared mode lock for same data item.
•
Lock may be granted before releasing a lock by transaction T3.
•
Transaction T1 never gets the exclusive mode lock and make progress.
•
Means T1 is starved.
When a transaction Ti requests a lock on a data item Q in a particular mode M ,
To avoid starvation , Concurrency control manager grants the lock provided :1) There is no other transaction holding a lock on Q in a mode that conflicts with M.
2) There is no other transaction that is waiting for a lock on Q and that made its lock
request before Ti.
Due to this a lock request will never get blocked by a lock request that is made later.
TWO PHASE LOCKING
PROTOCOL
1) Growing Phase :- A transaction may obtain locks, but may not release any lock.
2) Shrinking Phase :- A transaction may release locks , but may not obtain any new locks.
* Initially as a transaction is in growing phase, it acquires locks as needed.
* Once a transaction releases a lock, it enters in a shrinking phase, so no more lock requests.
* e.g. Transactions T3 and T4 are in two phase but not the transactions T1 and T2.
* End of growing phase is a lock point where transaction obtained its final lock.
* Two phase locking protocol does not ensure freedom from deadlock. (T3 & T4 in S2)
*
To being a serializable , schedules should be cascadeless.
*
Cascading rollback may occur under two phase locking .
*
e.g. In schedule 4, if transaction T5 failed after reading A read(A) by transaction T7- leads to
cascading rollback of T6 and T7.
* Cascading rollbacks can be avoided by a modification of Two Phase Locking protocol
i.e. Strict Two Phase Locking Protocol.
*
All exclusive locks taken by a transaction be held until that transaction commits.
*
So it prevents other transaction from reading the data.
* Rigorous Two Phase Locking Protocol - All locks be held until the transaction commits.
*
T5
With this, transaction can be serialised in the order in which they commit.
T6
T7
T8
T9
lock-X(A)
read (a1);
read (a1)
read(A)
read (a2);
read (a2)
lock-S(B)
read (a3);
display (a1+a2)
read(B)
……..
write(A)
……..
unlock(A)
……..
lock-X(A)
read (an);
read (A)
write (a1);
write (A)
Schedule 5
unlock(A)
lock-S(A)
read (A)
1) Conversion of shared mode lock to exclusive mode lock is
called UPGRADE.
2) Conversion of exclusive mode lock to shared mode lock is
called DOWNGRADE.
Partial Schedule 4 under
Two – Phase Locking
* If we execute with Two Phase Locking Protocol then T8 must lock a1 in exclusive mode.
* Due to this any concurrent transaction execution
is now serial.
* But here T8 needs exclusive lock at the end only.
* So if T8 could initially lock a1 in shared mode and then could later change the lock to exclusive
mode, we could get concurrency.
* e.g. Here T8 and T9 could access a1 and a2 simultaneously.
* If lock conversions are allowed ,then T8 can change the shared mode lock to exclusive mode
* Lock conversion cannot be allowed arbitrarily (randomly).
lock.
* UPGRADE can take place in only the Growing Phase.
* DOWNGRADING can take place in only the Shrinking Phase.
* Due to refined Two Phase Locking Protocol transactions T8 and T9 can execute concurrently .
* Two Phase Locking Protocol with Lock conversion generates only conflict serializable schedules.
* If exclusive locks are held until end of the transaction , the schedules are cascadeless.
* Strict Two Phase Locking and Rigorous Two Phase Locking are used extensively in commercial
database system.
T8
T9
lock-S (a1);
lock-S (a1);
lock-S (a2);
lock-S (a2);
lock-S (a3);
lock-S (a4);
unlock (a1);
unlock (a2);
lock-S(an);
upgrade(a1);
* A scheme automatically generates the appropriate lock and unlock instructions for
a transaction.
1) When a transaction Ti issues a read(Q) operation , the system issues a lock-S(Q) instruction
followed by the read(Q) instruction.
2) When a transaction Ti issues a write(Q) operation , the system checks to see whether Ti already
holds a shared lock on Q. If it does, then the system issues an upgrade(Q) instruction, followed by
the write(Q) instruction. Otherwise, the
system issues a lock-X(Q) instruction, followed by the
write(Q) instruction.
3) All locks obtained by a transaction are unlocked after that transaction commits or abort.
Implementation of Locking
* Lock Manager send a message for - granting a lock
- requesting rollback- in case of deadlock
- send acknowledge for unlocking
(or grant a lock to a waiting transaction)
* Data Structure used - For each data item that is currently locked.
(Linked List of records – in the order in which request arrived)
Uses Hash Table indexed on a name of data item. (Lock Table)
In the figure there are five different data items - I4 ,I7, I23 , I144, I912
* Linked List of Data Items used.
* List of transactions to whom lock is granted or are waiting.
* After receiving unlock message fro a transaction , corresponding records in the LL are deleted out.
* New grant request a per the graph is now granted.
* If transaction aborts , then all locks are released out. Waiting requests are also deleted out.
Graph Based Protocol
* To develop a protocol we should have a prior knowledge about how transaction will
access the database.
* Data item set D = {d1 , d2 , d3…..dn}
If di
dj Any transaction accessing both di and dj , must access di before dj.
Consider a tree protocol (restricted for only exclusive locks.)
Transaction Ti can lock a data item at most once and follow the following rules.
1) The first lock by Ti may be on any data item.
2) Subsequently, a data item Q can be locked by Ti only if the parent of Q is currently locked by Ti.
3) Data items may be unlocked at any time.
4) A data item that has been locked and unlocked by Ti cannot subsequently be relocked
by Ti.
* Transaction T10 holds locks on two disjoint subtrees.
* The tree protocol ensures conflict serialisability as well as freedom from deadlock.
* But it is not ensure about recoverability and cascadelessness.
* To ensure recoverability and cascadelessness , the protocol should be modified so that
a transaction should not release an exclusive lock until its end.
* But holding exclusive locks until the end of the transaction reduces concurrency.
* Alternative to improve concurrency and ensures recoverability - Record the transaction which performed the last write on data item (For each data item with
a uncommitted write)
- Whenever transaction Ti performs a read of an uncommitted data item, record a commit
dependency of Ti on the transaction that performed a last write to the data item.
- Transaction Ti is then not permitted to commit until the commit of all transactions on which
it has a commit dependency.
- If any one of the transaction aborts ,Ti must be aborted.
Advantage Over Two Phase Locking Protocol
* Deadlock Free – so no rollbacks are required.
* Unlocking may occur earlier – which require shorter waiting time – increases
concurrency.
Disadvantages
* A transaction may have to lock data items that it does not access.
* e.g. A transaction that needs to access data items A & J in the database graph must lock only A & J. But
here, along with A & J additional data items i.e. B , D and H are going to lock by the transaction.
* Additional locking increases locking overhead , additional waiting time and decrease in concurrency.
* Without prior knowledge of what data items will need to be locked , transactions will have to lock the root of
tree. It reduces concurrency greatly.
* Conflict serialisable schedules can’t be obtained through Tree Protocol .
Deadlock Handling
* A system is in deadlock state if there exists a set of transactions such that every transaction in the set is
waiting for another transaction in the set.
* T0 is waiting for data item that T1 holds , T1 is waiting for data item that T2 holds and so on.
* None of transaction make progress. So rollback is required.
* Rollback of a transaction may be partial - i.e. a transaction may be rollback to the point where it obtained a
lock whose release resolves the deadlock.
Dealing with Deadlock
* Deadlock Prevention Protocol - which ensures the system will never enter a deadlock state. Prevention is
commonly used if the probability that the system would enter a
deadlock state is relatively high.
* Deadlock Detection & Recovery - We allow the system to enter a deadlock state and then try to recover by
using a deadlock detection and recovery scheme.
Detection and recovery scheme requires :1) The run time cost overheads of maintaining the necessary information and of executing the detection
algorithm.
2) Also the potential losses inherent in recovery from deadlock. Deadlock Prevention
A1) No cyclic waits can occur due to lock requests or requiring all locks to be acquired
together.
Different Schemes for First Approach
1) a) Each transaction should lock all data items before it begins.
All are locked in one step or none are locked.
Disadvantage - 1) Every time it is very difficult to predict, what data items needed to be locked.
2) Utilisation of data items may be low, since many of the data items may be locked .
But unused for a long time.
b) Follow the ordering of data items. i.e. transaction lock data items only in a sequence consistent with the
ordering. (Tree protocol which follows partial ordering of data items.)
2) In conjunction with two phase locking protocol , once a transaction has locked a particular item, it can’t
request locks on items that precede that item in the ordering.
This scheme is easy to implement as set of data items accessed by a transaction is known before transaction
starts its execution.
A2) Whenever the wait for a lock could potentially results in a deadlock , rollback those
transactions instead of
waiting.
To prevent deadlocks preemption and transaction rollback technique is used.
In preemption , when a transaction T j requests a lock that transaction Ti holds ,
lock granted to Ti may be preempted by rolling back of Ti and granting of the lock to T j
To control preemption - Assign a unique timestamp , based on a counter or on the
system clock to each transaction when it begins.
Timestamp is used only to decide whether a transaction should wait or roll back.
If transaction is rolled back , then it should start with its old timestamp.
Deadlock Prevention Scheme using Timestamps
1) Wait-Die Scheme - Is a non-preemptive technique.
a) Transaction Ti requests a data item Q,
b) Data item Q is currently held by T j
c) If
TS(Ti) < TS (T j)
Ti is allowed to wait.
i.e. Ti is older than T j
d) If
TS ( Ti) > TS (T j)
Ti is rolled back.
i.e. Ti is younger than T j
1) Here if T14 requests a data item held by T15, then T14 will wait.
T14 is older than T15
2) If T16 requests a data item held by T15 , then T16 will be rolled back.
T16 is younger than T15
Deadlock Prevention Scheme using Timestamps
2) Wound-Wait Scheme - Is a preemptive technique.
Is a counterpart of wait die scheme.
a) Transaction Ti requests a data item Q,
b) Data item Q is currently held by T j
c) If
TS(Ti) > TS (T j)
d) If TS ( Ti) < TS (T j)
Ti is allowed to wait. i.e. Ti is younger than T j
T j is rolled back. i.e. Ti is older than T j
T j is wounded by Ti
1) Here if T14 requests a data item held by T15, then T15 will be rolled back.
T14 is older than T15 (T15 is wounded by T14)
[older get a chance]
2) If T16 requests a data item held by T15 , then T16 will wait.
T16 is younger than T15
* The major problem with both these schemes is unnecessary rollbacks may occur.
Lock Timeouts Approach
* A transaction in waiting list should wait for specified time.
* If lock has not granted within this time , the transaction is said to timeout and rolls itself back and restart and
allows other to proceed.
* This scheme falls somewhere between deadlock prevention, where deadlock will never occur and deadlock
detection and recovery.
*
This scheme is useful to implement where the transactions are too short and long waits are may cause
deadlocks.
* But it is very difficult to decide hoe long a transaction must wait before timing out.
* Too long a wait results in unnecessary delays once a deadlock has occurred.
* Too short a wait results in transaction rollback even when there is no deadlock, leading to wastage of
resources.
* Starvation is also possible with this scheme.
*
So this scheme has limited applicability.
Deadlock Detection and Recovery
* If a system does not employ some protocol that ensures deadlock freedom, then a detection and recovery must
be used.
* An algorithm examines the state of the system periodically to determine whether a deadlock has occurred.
* If deadlock then system must attempt to recover from deadlock.
* For that system must :1) maintain the information about current allocation of data items to transactions
and requests.
2) provide an algorithm that uses this information to determine , whether the system has entered a deadlock
state.
3) recover from a deadlock when the detection algorithm determines that a deadlock exists.
Deadlock Detection
*
A deadlock is detected with the help of wait for graph.
* When a wait for graph contains a cycle , there is a deadlock.
* To detect a deadlock , the system needs to maintain the wait for graph and periodically invoke an algorithm to
search a cycle in a graph.
* Transaction T17 is waiting for transaction T18 and T19.
* Transaction T19 is waiting for transaction T18.
* Transaction T18 is waiting for transaction T20.
* Graph having no cycle, so no deadlock.
* Here the transactions T18, T19 & T20 are all deadlocked.
* When to invoke detection algorithm?
1) How often does a deadlock occur?
2) How many transactions will be affected by the deadlock?
* If deadlock occur frequently, then the detection algorithm should be
invoked more frequently.
* Data items allocated to deadlocked transactions will be unavailable to other
transactions until the deadlock
can be broken. Meantime no of cycles may be grow.
* In worst case , we invoke the detection algorithm every time a request for allocation could not be granted
immediately.
Recovery from Deadlock
* Detection algorithm determines that a deadlock exist, the system must recover.
* Most common solution is to roll back one or more transactions.
* Three actions need to be taken
1) Selection of a Victim :- From set of deadlocked transaction , we must determine
which transaction or transactions to roll back.
Roll back those transactions that will incur the
minimum cost.
* How to determine cost of a rollback?
* Factors to determine the cost of Rollback :-
a. How long the transaction has computed and how much longer the transaction will compute before it
completes its designated task.
b. How many data items the transaction has used.
c. How many more data items the transaction needs for it to complete.
d. How many transactions will be involved in the rollback.
2) Rollback :- After the decision made for rollback of the particular transaction , we must determine how far
this transaction should be rolled back.
Simplest solution is total rollback. - Abort the transaction and restart it.
* To break down the deadlock , Partial Rollback is also useful. But it requires the additional information about
the state of all running transactions.
*
Specifically the sequence of lock requests , grants and updates performed by the transaction needs to be
recorded.
* The deadlock detection mechanism should decide which locks the selected transaction needs to release to
breakdown the deadlock.
*
Selected transaction must be rolled back to the point where it obtained the first of these locks. It should
undo all actions taken after that point.
3) Starvation :- * Selection of victim is based on a cost factor.
* Due to this factor, the same transaction may be chosen as a victim again and again.
* So the transaction never completes its designated task. i.e. Starvation.
* We must ensure that a transaction can be picked as a victim for a finite number of
times.
* So include number of rollbacks as a factor in cost finding factors.
Timestamp – Based Protocol
* Timestamp is assigned by the database system before transaction Ti starts execution.
* Timestamp of transaction Ti is denoted by TS(Ti).
* After assigning a timestamp to Ti , if transaction Tj enters , then TS(Ti) < TS(T j)
1) Use the value of the SYSTEM CLOCK as a timestamp when the transaction enters in the system.
OR
2) Use INCREMENTAL LOGICAL COUNTER. When transactions enters in a system, the
value of a counter is a timestamp value for a transaction.
* Timestamps of the transactions determine the serializability order.
* So if TS(Ti) < TS(T j), then the system must ensure that the produced schedule is equivalent to a serial
schedule where Ti appears before Tj.
* W-timestamp(Q) denotes the largest timestamp of any transaction that executed write(Q) successfully.
* R-timestamp(Q) denotes the largest timestamp of any transaction that executed read(Q) successfully.
* These timestamps are updated whenever a new read(Q) or write(Q) instruction is executed.
Timestamp – Ordering Protocol
* The protocol ensures that any conflicting read and write operations are executed in timestamp order.
1) Suppose that transaction Ti issues read(Q)
a. If TS(Ti) < W-timestamp(Q) , then Ti needs to read a value of Q that was already overwritten. Hence
read(Q) operation is rejected and Ti is rolled back.
b. If TS(Ti) >= W-timestamp(Q) , then read(Q) operation is executed, and R- timestamp(Q) is set to the
maximum of R-timestamp(Q) and TS(Ti).
2) Suppose that transaction Ti issues write(Q)
a. If TS(Ti) < R-timestamp(Q) , then the value of Q that Ti is producing the old value and would never
produce. So write(Q) is rejected and Ti is rolled back.
b. If TS(Ti) < W-timestamp(Q) , then Ti is attempting to write an obsolete value of Q. Hence write(Q) is
rejected and Ti is rolled back.
c. Otherwise , the system executes the write operation and sets W-timestamp(Q) to Ts(Ti).
* System assigns a new timestamp to the rolling back transaction.
(older)
T25
(younger)
TS(T25) < TS(T26)
T26
---------------------------------------------read(B)
* Schedules that are possible under the two
phase locking protocol, but are not possible
read(B)
under the timestamp protocol. And vice versa.
B:=B-50
write(B)
read(A)
* Time stamp ordering protocol ensures conflict
serialisability. Because conflicting operations
read(A)
are processed in timestamp order.
display(A+B)
A:=A+50
write(A)
* Protocol ensures freedom from deadlock,
since no transaction ever waits.
display(A+B)
* There is a possibility of starvation of long transactions if a sequence of conflicting short transactions cause
repeated restarting of the long transaction.
* So the conflicting transactions need to be temporarily blocked to avoid repeated
restarts.
* The protocol can generate schedules that are not recoverable. However, it can be extended to make the
schedules recoverable, in one of several ways :-
1) Recoverability and cascadelessness can be ensured by performing all writes together
at the end of the transaction.
Write must be atomic - while the writes are in progress, no transaction is permitted to access any of the
data item that has been written.
2) Recoverability and cascadelessness can also be guaranteed by using a limited from of locking, whereby
reads of uncommitted items are postponed until the transaction that updated the item commits.
3) Recoverability alone can be ensured by tracking uncommitted writes, and allowing a transaction Ti to
commit only after the commit of any transaction that wrote value that Ti read.
Thomas’ Write Rule
* Provides modification in timestamp ordering protocol that allows potential concurrency.
T27
T28
TS(T27) < TS(T28)
---------------------------------------------read(Q)
write(Q)
write(Q)
* When T27 attempts its write(Q) operation, at that time TS(T27) < W-timestamp(Q)
* As W-timestamp(Q) = TS(T28)
* So write(Q) by T27 is rejected and transaction T27 must be rolled back.
* But the rollback of T27 is required by the timestamp ordering protocol, it is unnecessary.
* T28 has already written Q. And the value that T27 attempting to write will never need to be read.
* Any transaction Ti (older) with TS(Ti) < TS(T28) that attempts a read(Q) will be rolled
back since TS(Ti) < W-timestamp(Q).
* Any transaction T j (younger) with TS(T j) > TS(T28) must read value of Q written by T28,
rather than the value that T27 is attempting to write.
* This observation leads to a modified version of the time stamp ordering protocol.
* In this protocol obsolete write operation can be ignored under certain circumstances.
* Read operation remains unchanged.
Actual Rule