Database systems One approach to avoiding deadlocks is to r

Database systems :

One approach to avoiding deadlocks is to require each transaction to announce all the locks it wants at the beginning, and to either grant all those locks or deny them all and make the transaction wait. Does this approach avoid deadlocks due to locking? Either explain why, or give an example of a deadlock that can arise.

Solution

Please follow the data and description :

Deadlock :

In a multi-process system or even in the context of multi threading, the concept of deadlock is an unwanted situation or an unexpected execution that arises in a shared resource environment, where a process indefinitely waits for a resource that is held by another process. This process is called as the Deadlock.

As an example, let us assume that there are a set of transactions namely T0, T1, T2, ...,Tn. Here the transaction T0 needs a resource named A to complete its task. But that the resource A is held by the other transaction and let it be T1, and there is a glitch where T1 is waiting for a resource B, which is in turn held by the transaction T2. Thus, all the processes wait for each other to release resources that are held with them. In this case, none of the processes can finish their task successfully. Thus this situation is known as a deadlock. It is suggested that they are not healthy for a system. In such case if a system is stuck in a deadlock, the transactions involved in the deadlock are either to be rolled back or to be restarted.

Deadlock Prevention :

The given approach of avoiding deadlocks like that the each transaction to announce all the locks it wants at the beginning, and to either grant all those locks or deny them all and make the transaction wait. This could not prevent the process of Deadlock and thus could not complete the process successfully.

There are even some approaches to avoid Deadlock namely,

a) Wait-Die Scheme
b) Wound-Wait Scheme

a) Wait-Die Scheme :

In this process, if a transaction requests to lock a resource, which is already held with a conflicting lock by another transaction, then one of the two may occur :

1) If Tr(Ti) < Tr(Tj) that is Ti, which is requesting a conflicting lock, is older than Tj, then the transaction Ti is allowed to wait until the resource is available.

2) If Tr(Ti) > Tr(tj) it means if Ti is younger than Tj, then the transaction Ti dies. After this the Ti is restarted later with a random delay but with the same timestamp.

b) Wound-Wait Scheme :

In this process, if a transaction requests to lock a resource, which is already held with conflicting lock by some another transaction, then one of the two may occur :

1) If Tr(Ti) < Tr(Tj), it means that the transaction Ti forces the Tj to be rolled back which means that the Ti wounds Tj. Tj is restarted later with a random delay but with the same timestamp.

2) If Tr(Ti) > Tr(Tj), it means that the transaction Ti is forced to wait until the resource is available.

Hope this is helpful.