Introduction to TimeStamp and Deadlock Prevention Schemes in DBMS
Deadlock occurs when each transaction T in a schedule of two or more transaction waiting for some item locked by some other transaction T‘ in the set. Thus, both end up in a deadlock situation, waiting for the other to release the lock on the item. Deadlocks are a common problem and we have introduced the problem while solving the Concurrency Control by the introduction of Locks. Deadlock avoidance is a major issue and some protocols were suggested to avoid them, like Conservative 2-PL and Graph Based protocols but some drawbacks are still there.
Here, we will discuss a new concept of Transaction Timestamp TS(Ti). A timestamp is a unique identifier created by the DBMS to identify a transaction. They are usually assigned in the order in which they are submitted to the system, so a timestamp may be thought of as the transaction start time.
There may be different ways of generating timestamps such as
- A simple counter that increments each time its value is assigned to a transaction. They may be numbered 1, 2, 3…. Though we’ll have to reset the counter from time to time to avoid overflow.
- Using the current date/time from the system clock. Just ensuring that no two transactions are given the same value in the same clock tick, we will always get a unique timestamp. This method is widely used.
Deadlock Prevention Schemes based on Timestamp…
As discussed, Timestamps are unique identifiers assigned to each transaction. They are based on the order in which Transactions are started. Say if T1 starts before T2 then TS(T1) will be less than (<) TS(T2).
There are two schemes to prevent deadlock called wound-wait and wait-die. Say there are two transactions Ti and Tj, now say Ti tries to lock an item X but item X is already locked by some Tj, now in such a conflicting situation the two schemes which prevent deadlock. We’ll use this context shortly.
- Wait_Die : An older transaction is allowed to wait for a younger transaction, whereas a younger transaction requesting an item held by an older transaction is aborted and restarted.
From the context above, if TS(Ti) < TS(Tj), then (Ti older than Tj) Ti is allowed to wait; otherwise abort Ti (Ti younger than Tj) and restart it later with the same timestamp.
- Wound_Wait : It is just the opposite of the Wait_Die technique. Here, a younger transaction is allowed to wait for an older one, whereas if an older transaction requests an item held by the younger transaction, we preempt the younger transaction by aborting it.
From the context above, if TS(Ti) < TS(Tj), then (Ti older than Tj) Tj is aborted (i.e., Ti wounds Tj) and restarts it later with the same Timestamp; otherwise (Ti younger than Tj) Ti is allowed to wait.
Thus, both the schemes end up aborting the younger of the two transactions that may be involved in a deadlock. It is done on the basis of the assumption that aborting the younger transaction will waste less processing which is logical. In such a case there cannot be a cycle since we are waiting linearly in both cases.
For GATE the theory for these two methods is enough, for more on this you may refer here.
Another group of protocols which prevents deadlock but does not require Timestamps. They are discussed below:
- No-waiting Algorithm : This follows a simple approach, if a Transaction is unable to obtain a lock, it is immediately aborted and then restarted after a certain time delay without checking if a deadlock will occur or not. Here, no Transaction ever waits so there is no possibility for deadlock.
This method is somewhat not practical. It may cause transaction to abort and restart unnecessarily.
- Cautious Waiting : If Ti tries to lock an item X but is not able to do because X is locked by some Tj. In such a conflict, if Tj is not waiting for some other locked item, then Ti is allowed to wait, otherwise abort Ti.
Another approach, to deal with deadlock is deadlock detection, we can use Wait-for-Graph. This uses a similar approach when we used to check for cycles while checking for serializability.
Starvation: One problem that may occur when we use locking is starvation which occurs when a transaction cannot proceed for an indefinite period of time while other transactions in the system continue normally. This may occur if the waiting scheme for locked items is unfair, giving priority to some transactions over others. We may have some solutions for Starvation. One is using a first come first serve queue; transactions are enabled to lock an item in the order in which they originally requested the lock. This is a widely used mechanism to reduce starvation. Our Concurrency Control Manager is responsible to schedule the transactions, so it employs different methods to overcome them. You may refer this for detailed explanation.
Try this question : GATE | GATE-CS-2017 (Set 1) | Question 46
Next, we’ll discuss the famous Timestamp Ordering Protocol and Thomas Write rule. Till then Happy Learning!
Reference: Database System Concepts, Fifth Edition [Silberschatz, Korth, Sudarshan], Chapter-16.