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.
- 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).
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.
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.
- 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.
This method is somewhat not practical. It may cause transaction to abort and restart unnecessarily.
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.
- Dirty read in SQL
- DBMS | Concurrency Control | Types of Schedules
- Implementation of Locking in DBMS
- DBMS | Concurrency Control Protocol | Multiple Granularity Locking
- DBMS | Concurrency Control Protocol | Thomas Write Rule
- DBMS | Concurrency Control Protocols | Timestamp Ordering Protocols
- DBMS | Concurrency Control Protocol | Graph Based Protocol
- DBMS | Concurrency Control Protocol | Two Phase Locking (2-PL)-III
- Starvation in DBMS
- Deadlock in DBMS
- DBMS | Database Recovery Techniques
- DBMS Architecture 2-Level, 3-Level
- Indexing in Databases | Set 1
- DBMS | Conflict Serializability
- DBMS | How to test if two schedules are View Equal or not ?
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.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