This content originally appeared on DEV Community and was authored by Pranjali Nandan
Before proceeding directly to the prevention of deadlock in DBMS, let's understand what deadlock is. Deadlock is a condition where one or more processes are waiting for a resource indefinitely, where this resource is acquired by another process.
For greater clarity, consider the following scenario: we have two resources, say R1 and R2, and we can have two processes, say P1 and P2. P1 has R2 resource, and P2 has R1 resource; therefore, P1 requires both R1 and R2 resources to complete its process, and P2 requires both R1 and R2 resources to complete its process. P1 process now holds R2 resource and waits indefinitely for R1 resource, similar to P2 process. So, these conditions are deadlock conditions where some processes are blocked because they hold some resources and are waiting for other processes that were held by other processes, so this waiting will never end until resolved.
So, we need to understand the conditions that can lead to a deadlock. So, according to Coffman, there are four conditions where deadlock can occur, which are mentioned below:
- Mutual exclusion
- Circular waiting situation
- Condition of hold and wait
- There is no preemption condition.
Prevention of Deadlock
When any transaction starts to execute, the database management system will inspect all its operations so that a deadlock condition will not occur. If it finds in any condition that a deadlock condition can occur, then that transaction is not allowed to be executed.
We can avoid deadlock by avoiding one or more of the four Coffman's conditions.
- Removing mutual exclusion, i.e., all the resources must be shareable.
- Removing the hold and wait condition
- Preemption of resources
- Avoid the condition of circular waiting.
Methods for Preventing Deadlocks
Deadlock prevention is very suitable for large databases. If all the resources were arranged in such a manner that the process did not need to wait for resources, then the deadlock could be prevented. The database management system analyses the situation of operations of a transaction and if there is any chance of deadlock occurring, then that transaction will never be executed. Let’s look at some methods of prevention:
- Wait-Die
- Wound-Wait
Wait-Die
The Wait-Die scheme is a non-preemptive technique to use for preventing deadlock. Suppose we have two transactions, T1 and T2.
When T1 requests data currently held by transaction T2, in this case, T1 is allowed to wait if and only if its timestamp is smaller than the timestamp of T2.
(In simple words, it means T1 is older than T2). If not, then T1 is going to die or be killed.
That is why this scheme is known as the "WAIT-DIE SCHEME."
In this technique, two possibilities may occur:
a) T1 timestamp < T2 timestamp = It means if T1 is older than T2, then T1 is allowed to wait until the resource is not provided to T1.
b) T1 timestamp > T2 timestamp = It means if T1 is younger than T2, then T1 is going to die. It is not allowed to wait.
So more precisely, we can say that if the transaction is older than the other transaction, then it has the right to wait, otherwise it is going to die.
Example
Let's consider this example. It will clear up all your doubts and the above theory in a simple manner.
Suppose we have a transaction T1, T2, T3 having a timestamp of 2, 4, 6, respectively.
- If T1 requests a resource that is held by T2, then T1 has the right to wait. What's the deal? because the T1 timestamp is earlier than the T2 timestamp
- If T3 requests a resource that is held by T2, then T3 is going to die. What's the deal? because the T3 timestamp is more recent than the T2 timestamp
I hope it is clear to all of you now.
Wound-Wait
The Wound-Wait scheme is a preemtive technique used in the prevention of deadlock in DBMS. It is the total opposite of the wait-die scheme.
Suppose we have two transactions, T1 and T2. If T1 requests data or a resource which is held by T2, then T1 is allowed to wait if and only if T1's timestamp is greater than T2. Otherwise, in this case, T2 is going to die instead of T1.
That means T2 is wounded by T1. That is why this scheme is known as the "Wound-wait" scheme in DBMS.
In this technique, 2 possibilities may occur, like in the wait-die scheme:
a) T1 timestamp < T2 timestamp = In this case, T2 is going to be killed by T1 and it will restart at a random delay but with the same timestamp.
b) T1 timestamp > T2 timestamp =It means if T1 is older than T2, then T1 is allowed to wait until the resource is not provided to T1.
Example
Let's consider this example. It will clear up all your doubts and the above theory.
Suppose we have a transaction T1, T2, T3 having a timestamp of 2, 4, 6, respectively.
- If T1 requests a resource that is held by T2, then T1 is going to force T2 and it will wound T2.
- If T3 requests a resource that is held by T2, then T3 has the right to wait.
For a better understanding of deadlocks, Read more about it on Scaler Topics
This content originally appeared on DEV Community and was authored by Pranjali Nandan
Pranjali Nandan | Sciencx (2022-02-10T11:39:48+00:00) How to Prevent Deadlock in DBMS?. Retrieved from https://www.scien.cx/2022/02/10/how-to-prevent-deadlock-in-dbms/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.