Deadlock occurs when each transaction T in a schedule of two or more transactions 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 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 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 the 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 a detailed explanation.
Timestamp-based concurrency control and deadlock prevention schemes are two important techniques used in database management systems to ensure transaction correctness and concurrency.
Timestamp-based concurrency control uses timestamps to order the execution of concurrent transactions. Each transaction is assigned a unique timestamp based on the system clock. When a transaction requests access to a data item, the system checks the timestamp of the transaction against the timestamp of the last transaction that accessed the same data item. If the timestamp of the requesting transaction is older than the timestamp of the last transaction that accessed the data item, the requesting transaction is rolled back to maintain the serializability of the transactions.
In addition, timestamp-based schemes use a validation procedure to check whether a transaction has read data that has been modified by another transaction after the first transaction has read it. If such a conflict is detected, the transaction is rolled back to ensure consistency and correctness.
Deadlock prevention schemes are used to prevent situations where two or more transactions are waiting for each other to release locks, resulting in a deadlock. Deadlocks occur when two transactions hold exclusive locks on resources that the other transaction needs to proceed. To prevent deadlocks, DBMSs use several schemes, including:
Timeout-based schemes: Transactions are allowed to hold a lock for a limited time. If a transaction exceeds its allotted time, it is rolled back, allowing other transactions to proceed.
Wait-die schemes: If a transaction requests a lock held by another transaction, the requesting transaction waits if its timestamp is older than the timestamp of the transaction holding the lock. If the timestamp of the requesting transaction is newer, it rolls back and is restarted with a new timestamp.
Wound-wait schemes: If a transaction requests a lock held by another transaction, the requesting transaction is granted the lock if its timestamp is newer than the timestamp of the transaction holding the lock. If the timestamp of the requesting transaction is older, the transaction holding the lock is rolled back and restarted with a new timestamp.
In conclusion, timestamp-based concurrency control and deadlock prevention schemes are important techniques in database management systems to ensure transaction correctness, consistency, and concurrency. These techniques help maintain data integrity and prevent situations where transactions are deadlocked or rolled back, ensuring efficient and effective database operations.
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!
Level Up Your GATE Prep!
Embark on a transformative journey towards GATE success by choosing Data Science & AI
as your second paper choice with our specialized course. If you find yourself lost in the vast landscape of the GATE syllabus, our program is the compass you need.