Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Deadlocks in DBMS
A deadlock occurs when two or more processes need some resource to complete their execution that is held by the other process. 
In the above diagram, process 1 has resource 1 and needs resource 2. Similarly process 2 has resource 2 and needs resource 1. Each of these processes needs the other’s resource to complete but neither of them is willing to relinquish their resources. So, process 1 and process 2 are in deadlock.
Coffman Conditions
A deadlock will only occur if the four Coffman conditions hold true. These conditions are not necessarily mutually exclusive. They are:
Mutual Exclusion
There should be a resource that can only be held by one process at a time. In the diagram below, there is a single instance of resource R1 and it is held by process P1 only.
Hold and Wait
A process can hold multiple resources and still request more resources from other processes which are holding them. In the diagram given below, process P1 holds resources R1 and R2 and is requesting the resource R3 which is held by process P2.
No Preemption
A resource cannot be preempted from a process by force. A process can only release a resource voluntarily. In the diagram below, process P1 cannot preempt resource R3 from Process P2. It will only be released when P2 relinquishes it voluntarily after its execution is complete.
Circular Wait
A process is waiting for the resource held by the second process, which is waiting for the resource held by the third process and so on, till the last process is waiting for a resource held by the first process. This forms a circular chain. For example: Process P1 is allocated resource R1 and it is requesting resource R2. Similarly, process P2 is allocated resource R2 and it is requesting resource R1. This forms a circular wait loop.
A process is waiting for the resource held by the second process, which is waiting for the resource held by the third process and so on, till the last process is waiting for a resource held by the first process. This forms a circular chain. For example: Process P1 is allocated resource R1 and it is requesting resource R2. Similarly, process P2 is allocated resource R2 and it is requesting resource R1. This forms a circular wait loop.
Deadlock Detection
The resource scheduler can detect a deadlock as it keeps track of all the resources that are allocated to different processes. After a deadlock is detected, it can be resolved using the following methods:
- All the processes involved in the deadlock are terminated. This is not a good approach as all the progress made by the processes is destroyed.
- Resources can be preempted from some processes and given to others till the deadlock is resolved.
Deadlock Prevention
It is imperative to prevent a deadlock before it can occur. So, the system rigorously checks each transaction before it is executed to make sure it does not lead to deadlock. If there is even a chance that a transaction may lead to deadlock, it is never allowed to execute.
There are some deadlock prevention schemes that use timestamps in order to make sure that deadlock does not occur. These are −
- Wait - Die Scheme
In the wait - die scheme, if a transaction T1 requests for a resource that is held by transaction T2, one of the following two possibilities may occur:
- TS(T1) < TS(T2) - If T1 is older than T2 i.e T1 came in the system earlier than T2, then it is allowed to wait for the resource which will be free when T2 has completed its execution.
TS(T1) > TS(T2) - If T1 is younger than T2 i.e T1 came in the system after T2, then T1 is killed. It is restarted later with the same timestamp.
- Wound - Wait Scheme
In the wound - wait scheme, if a transaction T1 requests for a resource that is held by transaction T2, one of the following two possibilities may occur:
- TS(T1) < TS(T2) - If T1 is older than T2 i.e T1 came in the system earlier than T2, then it is allowed to roll back T2 or wound T2. Then T1 takes the resource and completes its execution. T2 is later restarted with the same timestamp.
TS(T1) > TS(T2) - If T1 is younger than T2 i.e T1 came in the system after T2, then it is allowed to wait for the resource which will be free when T2 has completed its execution.
Deadlock Avoidance
It is better to avoid a deadlock rather than take measures after the deadlock has occurred. The wait for graph can be used for deadlock avoidance. This is however only useful for smaller databases as it can get quite complex in larger databases.
Wait for graph
The wait for graph shows the relationship between the resources and transactions. If a transaction requests a resource or if it already holds a resource, it is visible as an edge on the wait for graph. If the wait for graph contains a cycle, then there may be a deadlock in the system, otherwise not.
Ignore Deadlock - Ostrich Algorithm
The ostrich algorithm means that the deadlock is simply ignored and it is assumed that it will never occur. This is done because in some systems the cost of handling the deadlock is much higher than simply ignoring it as it occurs very rarely. So, it is simply assumed that the deadlock will never occur and the system is rebooted if it occurs by any chance.
6K+ Views
