DBMS | Introduction to TimeStamp and Deadlock Prevention Schemes



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 differnt 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 transaction are given 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 then(<) 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 prevents 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 abort Ti (Ti younger than Tj).

Thus, both the schemes end up in aborting the younger of the two transaction 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 the 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 Alogorithm : 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 serializablity.

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.



My Personal Notes arrow_drop_up


Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.



Improved By : Sriman Boora

Article Tags :
Practice Tags :



Be the First to upvote.


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.