What are Deadlocks?

Deadlock is a state of a database system having two or more transactions, when

each transaction is waiting for a data item that is being locked by some other
transaction. A deadlock can be indicated by a cycle in the wait-for-graph. This is a
directed graph in which the vertices denote transactions and the edges denote waits
for data items.
For example, in the following wait-for-graph, transaction T1 is waiting for data item X
which is locked by T3. T3 is waiting for Y which is locked by T2 and T2 is waiting for
Z which is locked by T1. Hence, a waiting cycle is formed, and none of the
transactions can proceed executing.

Deadlock Management in Centralized Systems

There are three classical approaches for deadlock handling, namely −

• Deadlock prevention.
• Deadlock avoidanc
• Deadlock detection and removal.
All of the three approaches can be incorporated in both a centralized and a distributed
database system.
Deadlock Prevention
The deadlock prevention approach does not allow any transaction to acquire locks
that will lead to deadlocks. The convention is that when more than one transactions
request for locking the same data item, only one of them is granted the lock.
One of the most popular deadlock prevention methods is pre-acquisition of all the
locks. In this method, a transaction acquires all the locks before starting to execute
and retains the locks for the entire duration of transaction. If another transaction
needs any of the already acquired locks, it has to wait until all the locks it needs are
available. Using this approach, the system is prevented from being deadlocked since
none of the waiting transactions are holding any lock.
Deadlock Avoidance
The deadlock avoidance approach handles deadlocks before they occur. It analyzes
the transactions and the locks to determine whether or not waiting leads to a
deadlock.
The method can be briefly stated as follows. Transactions start executing and request
data items that they need to lock. The lock manager checks whether the lock is
available. If it is available, the lock manager allocates the data item and the
transaction acquires the lock. However, if the item is locked by some other transaction
in incompatible mode, the lock manager runs an algorithm to test whether keeping
the transaction in waiting state will cause a deadlock or not. Accordingly, the algorithm
decides whether the transaction can wait or one of the transactions should be
aborted.
There are two algorithms for this purpose, namely wait-die and wound-wait. Let us
assume that there are two transactions, T1 and T2, where T1 tries to lock a data item
which is already locked by T2. The algorithms are as follows −
• Wait-Die − If T1 is older than T2, T1 is allowed to wait. Otherwise, if T1 is
younger than T2, T1 is aborted and later restarted.
• Wound-Wait − If T1 is older than T2, T2 is aborted and later restarted.
Otherwise, if T1 is younger than T2, T1 is allowed to wait.
Deadlock Detection and Removal
The deadlock detection and removal approach runs a deadlock detection algorithm
periodically and removes deadlock in case there is one. It does not check for deadlock
when a transaction places a request for a lock. When a transaction requests a lock,
the lock manager checks whether it is available. If it is available, the transaction is
allowed to lock the data item; otherwise the transaction is allowed to wait.
Since there are no precautions while granting lock requests, some of the transactions
may be deadlocked. To detect deadlocks, the lock manager periodically checks if the
wait-forgraph has cycles. If the system is deadlocked, the lock manager chooses a
victim transaction from each cycle. The victim is aborted and rolled back; and then
restarted later. Some of the methods used for victim selection are −

• Choose the youngest transaction.

• Choose the transaction with fewest data items.
• Choose the transaction that has performed least number of updates.
• Choose the transaction having least restart overhead.
• Choose the transaction which is common to two or more cycles.
This approach is primarily suited for systems having transactions low and where fast
response to lock requests is needed.

Deadlock Handling in Distributed Systems

Transaction processing in a distributed database system is also distributed, i.e. the
same transaction may be processing at more than one site. The two main deadlock
handling concerns in a distributed database system that are not present in a
centralized system are transaction location and transaction control. Once these
concerns are addressed, deadlocks are handled through any of deadlock prevention,
deadlock avoidance or deadlock detection and removal.
Transaction Location
Transactions in a distributed database system are processed in multiple sites and
use data items in multiple sites. The amount of data processing is not uniformly
distributed among these sites. The time period of processing also varies. Thus the
same transaction may be active at some sites and inactive at others. When two
conflicting transactions are located in a site, it may happen that one of them is in
inactive state. This condition does not arise in a centralized system. This concern is
called transaction location issue.
This concern may be addressed by Daisy Chain model. In this model, a transaction
carries certain details when it moves from one site to another. Some of the details are
the list of tables required, the list of sites required, the list of visited tables and sites,
the list of tables and sites that are yet to be visited and the list of acquired locks with
types. After a transaction terminates by either commit or abort, the information should
be sent to all the concerned sites.
Transaction Control
Transaction control is concerned with designating and controlling the sites required
for processing a transaction in a distributed database system. There are many options
regarding the choice of where to process the transaction and how to designate the
center of control, like −

• One server may be selected as the center of control.

• The center of control may travel from one server to another.
• The responsibility of controlling may be shared by a number of servers.
Distributed Deadlock Prevention
Just like in centralized deadlock prevention, in distributed deadlock prevention
approach, a transaction should acquire all the locks before starting to execute. This
prevents deadlocks.
The site where the transaction enters is designated as the controlling site. The
controlling site sends messages to the sites where the data items are located to lock
the items. Then it waits for confirmation. When all the sites have confirmed that they
have locked the data items, transaction starts. If any site or communication link fails,
the transaction has to wait until they have been repaired.
Though the implementation is simple, this approach has some drawbacks −
• Pre-acquisition of locks requires a long time for communication delays. This
increases the time required for transaction.
• In case of site or link failure, a transaction has to wait for a long time so that
the sites recover. Meanwhile, in the running sites, the items are locked. This
may prevent other transactions from executing.
• If the controlling site fails, it cannot communicate with the other sites. These
sites continue to keep the locked data items in their locked state, thus resulting
in blocking.
Distributed Deadlock Avoidance
As in centralized system, distributed deadlock avoidance handles deadlock prior to
occurrence. Additionally, in distributed systems, transaction location and transaction
control issues needs to be addressed. Due to the distributed nature of the transaction,
the following conflicts may occur −

• Conflict between two transactions in the same site.

• Conflict between two transactions in different sites.
In case of conflict, one of the transactions may be aborted or allowed to wait as per
distributed wait-die or distributed wound-wait algorithms.
Let us assume that there are two transactions, T1 and T2. T1 arrives at Site P and
tries to lock a data item which is already locked by T2 at that site. Hence, there is a
conflict at Site P. The algorithms are as follows −
• Distributed Wound-Die
o If T1 is older than T2, T1 is allowed to wait. T1 can resume execution
after Site P receives a message that T2 has either committed or aborted
successfully at all sites.
o If T1 is younger than T2, T1 is aborted. The concurrency control at Site
P sends a message to all sites where T1 has visited to abort T1. The
controlling site notifies the user when T1 has been successfully aborted
in all the sites.
• Distributed Wait-Wait
o If T1 is older than T2, T2 needs to be aborted. If T2 is active at Site P,
Site P aborts and rolls back T2 and then broadcasts this message to
other relevant sites. If T2 has left Site P but is active at Site Q, Site P
broadcasts that T2 has been aborted; Site L then aborts and rolls back
T2 and sends this message to all sites.
o If T1 is younger than T1, T1 is allowed to wait. T1 can resume execution
after Site P receives a message that T2 has completed processing.
Distributed Deadlock Detection
Just like centralized deadlock detection approach, deadlocks are allowed to occur
and are removed if detected. The system does not perform any checks when a
transaction places a lock request. For implementation, global wait-for-graphs are
created. Existence of a cycle in the global wait-for-graph indicates deadlocks.
However, it is difficult to spot deadlocks since transaction waits for resources across
the network.
Alternatively, deadlock detection algorithms can use timers. Each transaction is
associated with a timer which is set to a time period in which a transaction is expected
to finish. If a transaction does not finish within this time period, the timer goes off,
indicating a possible deadlock.
Another tool used for deadlock handling is a deadlock detector. In a centralized
system, there is one deadlock detector. In a distributed system, there can be more
than one deadlock detectors. A deadlock detector can find deadlocks for the sites
under its control. There are three alternatives for deadlock detection in a distributed
system, namely.
• Centralized Deadlock Detector − One site is designated as the central
deadlock detector.
• Hierarchical Deadlock Detector − A number of deadlock detectors are
arranged in hierarchy.
• Distributed Deadlock Detector − All the sites participate in detecting
deadlocks and removing them.