Introduction to TimeStamp and Deadlock Prevention Schemes in DBMS

Deadlock in DBMS

Deadlock in DBMS is a situation where some transaction T is waiting for another transaction, and another transaction is locked due to some other transaction. So, it is a big problem in DBMS where all transactions wait for each other, and no transaction is completed. There are a lot of algorithms and schemes used for avoidance, ignorance, and prevention of deadlocks. Due to deadlock, we can face many problems in which starvation is one of the problems.

Starvation

When in the database, one transaction is not getting the resource by infinite time, and other transactions are processing normally, then this situation is called Starvation. Starvation can occur when the resource locking is given unfairly to the transactions.

Transaction TimeStamp in DBMS

The timestamp is an identifier that is used to identify each transaction uniquely on the system. We can consider it as the start time of a transaction. So, each transaction gets its timestamp in the same order as they are submitted in the system. There can be several schemes to assign the timestamps to the transactions, like we can give each transaction a number incremented by each transaction, like 1,2,3, etc. Another way is that we can assign each transaction's current time with the date as a timestamp from the system clock so that each one will get a unique timestamp. The second method is widely used to assign the timestamps.

Deadlock prevention schemes in DBMS

To prevent the deadlocks, we have a lot of schemes available. Let's suppose we have an item A which is held by transaction i and timestamp id TS(i) now. If transaction j requires item A with timestamp TS(j) so we have to abort one of the transactions. So, we will discuss two schemes based on the timestamps:

• wait_die:

Let's suppose transaction i T_i is older than transaction j Tj. So, the timestamp of i will be lesser than the timestamp of j. TS(i) < TS(j).

There can be two situations in this scheme:

If the resource A is held by Tj, then the older transaction T_i will wait for the complete execution of the younger transaction, and then it uses the resource A.

If the resource A is held by the older transaction T_i, then Tj will not wait, and it will be killed. Now the younger transaction will restart with the same timestamp later.

• Wound_wait:

Let's suppose transaction i T_i is older than transaction j Tj. So, the timestamp of i will be lesser than the timestamp of j. TS(i) < TS(j).

There can be two situations in this scheme:

If the resource A is held by T_i, then the younger transaction Tj will wait for the complete execution of the older transaction, and then it uses the resource A.

If the resource A is held by the younger transaction Tj then T_i will not wait, and the younger transaction will be killed. Now the younger transaction will restart with the same timestamp later with some delay.

So, from both schemes, we can determine that the younger transaction will always be killed because it requires less processing, and it is more beneficial to kill the younger transaction than the older one.

Another scheme for deadlock prevention can be used, which does not require timestamps are described below:

• No-Waiting algorithm:

This is one of the naive approaches to preventing the deadlock. In this scheme, if a transaction needs a resource but if the resource is not available, then it will be aborted instantly. No transaction will wait for the resource, and once it is aborted, it will restart after some time with some delay. So, in this scheme, there is no waiting for the transaction, so there is no chance of deadlock. But practically, it is not a good solution because this scheme aborts the transaction many times unnecessarily.

• Cautious - Waiting:

In this scheme, if a transaction requires some resource and if the resource is locked by another transaction. If that other transaction is not waiting for another transaction but holding the resource unnecessarily, then the first transaction will have to wait for the resource to be available; otherwise, it can abort itself.