Chapter 9

Distributed Deadlock Management

This chapter introduces different deadlock management techniques to handle deadlock

situation in a distributed database system. Distributed deadlock prevention, distributed
deadlock avoidance, and distributed deadlock detection and recovery methods are briefly
discussed in this chapter.

The outline of this chapter is as follows. Section 9.1 addresses the deadlock problem and
the deadlock prevention methods for distributed system are discussed in Section 9.2. In
Section 9.3, distributed deadlock avoidance has been represented. The techniques for
distributed deadlock detection and recovery are focused in section 9.4.

9.1 Introduction to Deadlock

In a database environment, a deadlock is a situation where transactions are waiting for

one another. Any lock based concurrency control algorithm and some timestamp based
concurrency control algorithms may result in deadlocks, since these algorithms require
transactions to wait for one another. In lock based concurrency control algorithms, locks
on data items are acquired in mutually exclusive manner, thus, it may cause deadlock
situation. Whenever a deadlock situation arises in a database environment, the outside
interference is required to continue the normal execution of the system. Therefore, the
database system requires special procedures to resolve the deadlock situation.

Deadlock situation can be characterized by wait-for graphs, directed graphs that indicate
which transactions are waiting for which other transactions. In a wait-for graph, nodes of
the graph represent transactions and edges of the graph represent the waiting for
relationships among transactions. An edge is drawn in the wait-for graph from transaction
Ti to transaction Tj if the transaction Ti is waiting for the lock on a data item that is
currently hold by the transaction Tj. Using wait-for graph, it is very easy to detect
whether a deadlock situation has occurred in a database environment or not. There is a
deadlock in the system if and only if the corresponding wait-for graph contains a cycle.

The resolution of deadlock situation is much easier in centralized DBMS than that of
distributed DBMS. In a centralized DBMS, only one local wait-for graph is drawn to
detect the deadlock situation. The detection of deadlock in a distributed DBMS is more
complicated, because the circular waiting situation which determines a deadlock situation
may involve several different sites. Thus, in a distributed DBMS it is not sufficient to
draw a local wait-for graph for each local DBMS only, but it is also necessary to draw a
global wait-for graph for the entire system to detect deadlock situation. In a distributed
database, a local wait-for graph is a portion of the global wait-for graph which consist
only those nodes and edges that are completely contained at a single site. Three general
techniques are available for deadlock resolution in a distributed database system. These
are distributed deadlock prevention, distributed deadlock avoidance and distributed
deadlock detection and recovery from deadlock which are described in the following.

167
Example 9.1

Let us assume that in a database environment, there are two transactions T1 and T2
respectively. Further assume that the transaction T1currently holding an exclusive lock on
data item P and the transaction T2 holding an exclusive lock on data item Q. Now, if the
transaction T1 requires a write operation on data item Q, the transaction T 1 has to wait
until the transaction T2 releases the lock on the data item Q. However, in the meantime if
the transaction T2 requires a read or a write operation on the data item P, the transactions
T2 also has to wait for the transaction T1. In this situation, both the transactions T1 and T2
has to wait for one another indefinitely to release their respective locks and no transaction
can proceed for execution, thereby deadlock situation arises.

9.2 Distributed Deadlock Prevention

Distributed Deadlock prevention is a cautious scheme in which a transaction is

restarted when the system is afraid that deadlock might occur. Deadlock prevention is an
alternative method to resolve deadlock situation in which a system is designed in such a
way that deadlock is impossible. In this scheme, the transaction manager checks a
transaction when it is first initiated and does not permit to proceed if there is a risk that it
may causes deadlock. In case of lock based concurrency control, deadlock prevention in a
distributed system is implemented in the following way.

Let us consider a transaction Ti is initiated at a particular site in a distributed database

system which requires a lock on a data item that is currently owned by another
transaction Tj. Hence, a deadlock prevention test is done to check whether there is any
possibility of deadlock occurrence in the system. The transaction Ti is not permitted to
enter into a wait state for the transaction Tj if there is a risk of deadlock situation. In this
case, one among the two transactions is aborted to prevent deadlock. The deadlock
prevention algorithm is called non-preemptive if the transaction Ti is aborted and
restarted. On the other hand, if the transaction Tj is aborted and restarted, then the
deadlock prevention algorithm is called preemptive. The transaction Ti is permitted to
wait for the transaction Tj as usual if they pass the prevention test. The prevention test
must guarantee that if Ti is allowed to wait for Tj, then deadlock can never occur. Here,
one simple approach to prevent deadlock situation is that the transaction T i never waits
for the transaction Tj, but it forces to a number of restarts.

A better approach to implement deadlock prevention test is by assigning priorities to

transactions and to check priorities for determining whether one transaction would wait
for the other transaction or not. These priorities can be assigned by using a unique
identifier for each transaction in the distributed system. For instance, consider i and j are
the priorities of two transactions Ti and Tj respectively. Hence, the transaction Ti would
wait for the transaction Tj, if Ti has a lower priority than Tj, that is, i<j. This approach
prevents deadlock but one problem with this approach is that cyclic restart is possible.
Thus, some transactions could be restarted repeatedly without ever finishing.

168
One solution to the above problem is that using unique timestamp value of each
transaction as the priority of the transaction. One way to obtain a global timestamp value
for every transaction in a distributed system is that a unique local timestamp value is to
be assigned to each transaction by its local transaction manager and the site identifier will
be appended to the low-order bits with this value. Hence, timestamp values are unique
throughout the distributed system and do not require that clocks at different sites should
be synchronized precisely. Based on timestamp values, there are two different techniques
for deadlock prevention, known as Wait-die and Wound-Wait.

Wait-die is a non-preemptive deadlock prevention technique based on timestamp values

of transactions and implemented in the following way. In this technique, when one
transaction is about to block and waiting for a lock on a data item that is already locked
by another transaction, timestamp values of both the transactions are checked to give
priority to the older transaction. If a younger transaction is holding the lock on the data
item then the older transaction is allowed to wait, but if an older transaction is holding the
lock the younger transaction is aborted and restarted with the same timestamp value. This
forces the wait-for graph to be directed from older to younger transactions, making cyclic
restarts impossible. For example, if the transaction Ti requests a lock on a data item which
is already locked by the transaction Tj, then Ti is permitted to wait only if Ti has a lower
timestamp value than Tj. On the other hand, if Ti is younger than Tj, then Ti is aborted and
restarted with the same timestamp value.

Wound-Wait is an alternative preemptive deadlock prevention technique by which cyclic

restarts can be avoided. In this method, if a younger transaction requests for a lock on a
data item that is already hold by an older transaction, the younger transaction is allowed
to wait until the older transaction releases the corresponding lock. In this case, the wait-
for graph flows from younger to older transactions and cyclic restart is again avoided. For
instance, if the transaction Ti requests a lock on a data item which is already locked by
the transaction Tj, then Ti is permitted to wait only if Ti has a higher timestamp value than
Tj, otherwise, the transaction Tj is aborted and the lock is granted to the transaction Ti.

The deadlock situation cannot arise and the younger transaction is restarted in both the
above methods. The main difference between the two techniques is that whether they
preempt the active transaction or not. In wait-die method a transaction can only be
restarted when it requires accessing a new data item for the first time. A transaction that
has acquired locks on all the required data items will never be aborted. In wound-wait
method, it is possible that a transaction that has already hold a lock on a data item is
aborted, because another older transaction may request the same data item. Wait-die
method gives preference to younger transactions and aborts older transactions, since older
transactions wait for younger ones and it tends to wait longer as it gets older. On the other
hand, wound-wait method prefers older transactions since an older transaction never
waits for a younger transaction. In wait-die method, it is possible that a younger
transaction is aborted and restarted for a number of times if the older transaction holds
the corresponding lock for a long time, while in wound-wait method the older transaction
is aborted and restarted for a single time.

169
The main disadvantage of deadlock prevention scheme is that it may result unnecessary
waiting and rollback. Furthermore, some deadlock prevention scheme may require more
sites in a distributed system are to be involved in the execution of a transaction.

9.3 Distributed Deadlock Avoidance

Distributed deadlock avoidance is another technique to ensure that the deadlock

situation will not occur in the distributed system. Preordering of resources is a deadlock
avoidance technique in which each data item in the database system are numbered and
each transaction requests locks on these data items in that numeric order. This technique
requires that each transaction obtains all its locks before execution and numbering of data
items can be done either globally or locally. In distributed database system, it is necessary
that all sites should be numbered and transactions that requires to access data items from
multiple sites must request the corresponding locks by visiting the sites according to the
predefined number. The priority of a transaction is the highest number among the locks
that is already owned by the corresponding transaction. In this method, since a
transaction can only wait for those transactions that have higher priorities, no deadlock
situation can occur.

Deadlock avoidance methods are more suitable than deadlock prevention schemes for
database environments, but it requires runtime support for deadlock management, which
adds runtime overheads in transaction execution. Further, in addition to requiring
predeclaration of locks, a principal disadvantage of this technique is that it forces locks to
be obtained sequentially, which tends to increase response time.

9.4 Distributed Deadlock Detection and Recovery

Deadlock detection and recovery is the most popular and suitable technique for
deadlock management in database environment. In deadlock detection and recovery
method, first it is detected whether any deadlock has occurred or not in the system. After
detection of a deadlock situation in the system, the victim transaction is chosen and
aborted in order to resolve the deadlock situation. Deadlock situations are detected by
explicitly constructing the wait-for graph and searching it for cycles. A cycle in the wait-
for graph indicates that deadlock has occurred and one transaction in the cycle is chosen
as victim, which is aborted and restarted. To minimize the cost of restarting, the victim
selection is usually based on the amount of data items used by each transaction in the
cycle.

The principal difficulty to implement deadlock detection in a distributed database

environment is constructing global wait-for graph (GWFG) efficiently. In a distributed
DBMS, a local wait-for graph (LWFG) for each local DBMS can be drawn easily,
however, these local wait-for graphs are not sufficient to characterize all deadlock
situations in the distributed system. For example, consider there are three different sites in
a distributed system and each site has constructed a local wait-for graph as shown in the
figure 9.1. The local wait-for graph in each site is constructed in the usual manner using
local transactions and data items into that particular site. A cycle in local wait-for graph

170
indicates that a deadlock has occurred locally. The local wait-for graphs in figure 9.1
illustrated that no deadlock has occurred locally in three different sites since there are no
cycle in local wait-for graphs but it does not guarantee that no deadlock has occurred
globally. In order to detect deadlock situation in the distributed system, it is necessary to
construct a global wait-for graph from these different local wait-for graphs and searching
it for cycles.

T1 T2 T5 T1
T2 T3

T5 Site 3
Site 2

Site 1

Figure 9.1 Local Wait-for Graphs at different sites

The corresponding global wait-for graph in figure 9.2 illustrated that a deadlock has
occurred in the distributed system although no deadlock has occurred locally.

T1 T2 T3

T5

Figure 9.2 Global Wait-for Graph for Figure 9.1

171
There are three different techniques for detecting deadlock situation in the distributed
system. These are Centralized deadlock detection, Hierarchical deadlock detection
and Distributed deadlock detection which are described in the following.

9.4.1 Centralized Deadlock Detection

In Centralized Deadlock Detection method, a single site is chosen as Deadlock

Detection Coordinator (DDC) for the entire distributed system. The deadlock detection
coordinator is responsible for constructing the global wait-for graph (GWFG) for the
system. Each lock manager in the distributed database system transmits its local wait-for
graph to the deadlock detection coordinator periodically. The deadlock detection
coordinator constructs the global wait-for graph from these local wait-for graphs and
checks for the cycles in it. The occurrence of global deadlock situation is detected if there
are one or more cycles in the global wait-for graph. The deadlock detection coordinator
must break each cycle in the global wait-for graph by selecting the transactions to be
rolled back and restarted for recovery from the deadlock situation. The information
regarding the transactions that are to be rolled back and restarted must be transmitted to
the corresponding lock manager by the deadlock detection coordinator.

In order to minimize the communication cost, the deadlock detection coordinator can
only send the changes that have to be made in the local wait-for graph to the lock
manager. These changes represent the addition or removal of edges in the local wait-for
graph. The actual length of a period for global deadlock detection is a system design
decision and it is a trade-off between the communication cost of the deadlock detection
process and the cost of determining deadlocks late. The communication cost increases if
the length of the period is larger while some deadlocks in the system are undetected if the
length of the deadlock detection period is smaller.

The centralized deadlock detection approach is very simple, but it has several drawbacks.
This method is less reliable, since the failure of the central site causes the deadlock
detection impossible. The communication cost is very high in this case, since other sites
in the distributed system send their local wait-for graphs to the central site. Another
disadvantage of centralized deadlock detection technique is that false deadlocks can
detected for which the deadlock recovery procedure may be initiated, although no
deadlock has occurred. In this method, unnecessary rollbacks and restarts of transactions
may also results due to phantom deadlocks. (The details about false deadlock and
phantom deadlock have been discussed in Section 9.4.4).

9.4.2 Hierarchical Deadlock Detection

Hierarchical deadlock detection method reduces the communication overhead of

centralized deadlock detection method. With this approach, all sites in a distributed
database system are organized into a hierarchy and a complete tree of deadlock detectors
is constructed instead of a single centralized deadlock detector. Each site in the
distributed system sends its local wait-for graph to the deadlock detection site above it
(adjacent parent node) in the hierarchy. Thus, local deadlock detection is performed in the

172
leaf nodes of the tree, while the non-leaf nodes are responsible for detecting any deadlock
situation involving all its child nodes. The hierarchical deadlock detection method is
illustrated with an example in the figure 9.3.

In the following figure local deadlock detection is performed at leaf nodes site1, site2,
site3, site4 and site5. The deadlock detector at site6, namely DD12, is responsible for
detecting any deadlock situation involving its child nodes site1 and site2. Similarly, site3,
site4 and site5 send their local wait-for graphs to site7 and the deadlock detector at site7
searches for any deadlock involving its adjacent child nodes. A global deadlock detector
exists at the root of the tree that would detect the occurrence of global deadlock situation
for the entire distributed system. Hence, the global deadlock detector resides at site 8 that
would detect the deadlock between site6 and site7.

Site8
GDD

Site6 DD12 Site7

DD345

Site Site Site Site Site

1 2 3 4 5

Figure 9.3 Hierarchical Deadlock Detection

The performance of a hierarchical deadlock detection approach depends on the

hierarchical organization of nodes of the system. This organization should reflect the
network topology and the pattern of access requests to different sites of the network. This
approach is more reliable than centralized deadlock detection since it reduces the
dependence on central site and thereby it reduces the communication cost. However, it is
considerably more complicated to implement hierarchical deadlock detection method,
particularly in the presence of site and communication link failures. In this approach,
false deadlocks may also be detected.

173
9.4.3 Distributed Deadlock Detection

In distributed deadlock detection method, a deadlock detector exists at each site of the
distributed system. In this method, each site has the same responsibility and there is no
such distinction like local and global deadlock detector. A variety of approaches had
been proposed for distributed deadlock detection algorithm, but the most well-known and
simplified version which is presented here was developed by R. Obermarck at 1982.

In this approach, a local wait-for graph is constructed for each site by the local deadlock
detector. An additional external node is added to the local wait-for graph since each site
in the distributed system receives the potential deadlock cycles from other sites. In
distributed deadlock detection algorithm, the external node Tex is added to local wait-for
graph in order to indicate whether any transaction from remote sites is waiting for the
data item that is being held by the transaction at local site or any transaction from local
site is waiting for the data item that is currently being used by the transaction at remote
sites. For instance, an edge from the node Ti to Tex exists in the local wait-for graph, if the
transaction Ti is waiting for a data item that is already being held by any transaction at
remote site. Similarly, an edge from the external node Tex to Ti exists in the graph, if a
transaction from remote site is waiting to acquire a data item that is currently being held
by the transaction Ti at local site. Hence, the local detector checks for two things in order
to determine deadlock situation. If a local wait-for graph contains a cycle that does not
involve the external node Tex, then it indicates that one deadlock has occurred locally and
it can be handled locally. On the other hand, a global deadlock potentially exists if the
local wait-for graph contains a cycle involving the external node Tex. However, the
existence of such a cycle does not necessarily imply that there is global deadlock, since
the external node Tex represents different agents.

The local wait-for graphs are merged in order to determine the global deadlock situation.
To prevent sites from transmitting their local wait-for graphs to each other, a simple
strategy is followed here. In this strategy, one timestamp value is allocated to each
transaction and imposes the rule that one site Si transmits its local wait-for graph to the
site Sk, if a transaction, say, Tk at site Sk is waiting for the data item that is currently being
held by the transaction Ti at site Si and ts(Ti) < ts(Tk). If ts(Ti) < ts(Tk), the site Si
transmits its local wait-for graph to the site Sk and the site Sk add this information to its
local wait-for graph and check for cycles not involving the external node Tex in the
extended graph. If there is no cycle in the extended graph, the process continues until a
cycle appears and it may happen that the entire global wait-for graph is constructed and
no cycle has been detected. In this case, it is decided that there is no deadlock in the
entire distributed system. On the other hand, if the global wait-for graph contains a cycle
without involving the external node Tex, it is concluded that deadlock has occurred in the
system. The distributed deadlock detection method is illustrated in figure 9.4.

174
 Ti Site 2 Tj Site 3 Tk Site 1

Tex Tex Tex

Tk Site 3 Ti Site 1 Tj Site 2

Site 1 Site 2 Site 3

Figure 9.4 Distributed Deadlock Detection

After detecting a deadlock in the system, an appropriate recovery protocol is invoked to

resolve the deadlock situation. Hence, one or more transactions are chosen as victim and
these transactions are rolled back and restarted together with all their sub transactions.

The major benefit of distributed deadlock detection algorithm is that it is potentially more
robust than centralized or hierarchical methods. The deadlock detection is more
complicated in this method, because no single site contains all the information that is
necessary to detect global deadlock situation in the system and therefore substantial inter-
site communication is required which increases the communication overhead. Another
disadvantage of distributed deadlock detection approach is that it is more vulnerable to
the occurrence of false deadlocks than centralized or hierarchical methods.

9.4.4 False Deadlocks

In order to handle the deadlock situation in distributed database system, a number of

messages are transmitted among the sites. On the other hand, both in centralized and
hierarchical deadlock detection methods, local wait-for graphs are propagated
periodically to one or more deadlock detector sites in the system. The periodic nature of
this transmission process causes two problems. First, the delay which is associated with
the transmission of messages that is necessary for deadlock detection can cause the
detection of false deadlocks. For instance, consider at a particular time the deadlock
detector has received the information that the transaction Ti is waiting for the transaction
Tj. Further assume that after some time the transaction T j releases the data item which is
requested by the transaction Ti and requests for data item that is being currently held by
the transaction Ti. If the deadlock detector receives the information that the transaction Tj
is requested for the data item that is held by the transaction T i before receiving the
information that the transaction Ti is not blocked by the transaction T j any more, a false
deadlock situation is detected.

175
Another problem is that a transaction Ti which blocks another transaction may be
restarted for reasons that are not related to deadlock detection. In this case, until the
restart message of the transaction Ti is transmitted to the deadlock detector, the deadlock
detector can find a cycle in the wait-for graph that includes the transaction T i. Hence, one
deadlock situation is detected by the deadlock detector and this is called phantom
deadlock. When the deadlock detector detects a phantom deadlock, it may unnecessarily
restart a transaction other than Ti. In order to avoid unnecessary restarts for deadlocks,
special safety measures are required.

9.5 Chapter Summary

• In a database environment, a deadlock is a situation where transactions are waiting

for one another. Deadlock situation can be characterized by wait-for graphs, directed
graphs that indicate which transactions are waiting for which other transactions. The
handling of deadlock situation is more complicated in distributed DBMS than that of
centralized DBMS, since it involves a number of sites. Three general techniques are
available for deadlock resolution in a distributed database system such as distributed
deadlock prevention, distributed deadlock avoidance and distributed deadlock
detection and recovery from deadlock.

• Distributed Deadlock Prevention – Distributed deadlock prevention is a cautious

scheme in which a transaction is restarted when the distributed database system is
afraid that deadlock might occur. Deadlock prevention approach may be preemptive
or non-preemptive. Two different techniques are available for deadlock prevention
based on transaction timestamp values such as Wait-die and Wound-Wait.

• Distributed Deadlock Avoidance - Distributed deadlock avoidance is an alternative

method in which each data item in the database system are numbered and each
transaction requests locks on these data items in that numeric order in order to avoid
the deadlock situation.

• Distributed Deadlock Detection and Recovery - In distributed deadlock detection

and recovery method, first it is detected whether any deadlock situation has occurred
or not in the distributed system. After detection of a deadlock situation in the system,
the victim transaction is chosen and aborted in order to resolve the deadlock situation.
There are three different techniques for detecting deadlock situation in the distributed
system such as Centralized deadlock detection, Hierarchical deadlock detection
and Distributed deadlock detection.

• In order to handle the deadlock situation in distributed database system, a number of

messages are transmitted periodically among the sites which may causes two
problems such as false deadlock and phantom deadlock.

176
9.6 Review Questions

1. Discuss how you perform deadlock management in distributed DBMS.

2. Explain the working principles of Wait-Die and Wound-Wait algorithm for deadlock
prevention.
3. Differentiate between preemptive and non-preemptive methods for distributed
deadlock prevention.
4. Explain the algorithm for distributed deadlock avoidance.
5. What is the additional threat to handle deadlock situation from centralized to
distributed DBMS? Discuss the effect of replication to create deadlock.
6. Explain the phantom deadlock with example. Describe and compare the centralized
and distributed deadlock detection techniques for distributed DBMS.
7. Compare and contrast between centralized and hierarchical deadlock detection
methods.
8. What is false deadlock? Discuss with example.
9. Which deadlock handling method is more suitable for deadlock management in
distributed system? Justify your answer.

Exercises

1. Multiple Choice Questions:

(i) Deadlock situation can be characterized by

a. Resource allocation graphs
b. Weighted resource allocation graphs
c. Wait-for graphs
d. None of these.

(ii) Which of the following method is best suitable for deadlock handling in
distributed system?
a. Deadlock prevention
b. Deadlock avoidance
c. Deadlock detection and recovery
d. All of these.

(iii) Wait-die is a
a. Non-preemptive deadlock avoidance algorithm
b. Preemptive deadlock prevention algorithm
c. Non-preemptive deadlock prevention algorithm
d. Preemptive deadlock avoidance algorithm.

(iv) Wound-wait is a
a. Non-preemptive deadlock avoidance algorithm
b. Preemptive deadlock prevention algorithm
c. Non-preemptive deadlock prevention algorithm
d. Preemptive deadlock avoidance algorithm.

177
(v) In wait-die technique
a. Older transaction is allowed to wait for younger transaction
b. Younger transaction is allowed to wait for older transaction
c. Both a. and b.
d. None of the above.

(vi) In wound-wait technique

a. Older transaction is allowed to wait for younger transaction
b. Younger transaction is allowed to wait for older transaction
c. Both a. and b.
d. None of the above.

(vii) Which of the following statement is true?

a. In wait-die technique, older transaction is restarted
b. In wound-wait technique, older transaction is restarted
c. In both cases, younger transaction is restarted
d. None of the above.

(viii) Which of the following is a deadlock avoidance technique?

a. Wound-wait
b. Wait-die
c. Both a. and b.
d. Preordering of resources.

(ix) A cycle in local wait-for graph indicates

a. There is a possibility of local deadlock
b. There is a possibility of global deadlock
c. A deadlock has occurred locally
d. A deadlock has occurred globally.

(x) A cycle in global wait-for graph without external node indicates

a. There is a possibility of local deadlock
b. There is a possibility of global deadlock
c. A deadlock has occurred locally
d. A deadlock has occurred globally.

(xi) A cycle in global wait-for graph with external node indicates

a. There is a possibility of local deadlock
b. There is a possibility of global deadlock
c. A deadlock has occurred locally
d. A deadlock has occurred globally.

178
(xii) A deadlock detector exists in each site of the distributed system
a. In centralized deadlock detection
b. In hierarchical deadlock detection
c. In distributed deadlock detection
d. Both in hierarchical and distributed deadlock detection.

(xiii) More than one deadlock detector exists

a. In centralized deadlock detection
b. In hierarchical deadlock detection
c. In distributed deadlock detection
d. Both in hierarchical and distributed deadlock detection.

(xiv) Which of the following statement is correct?

a. False deadlocks occur due to communication delay
b. Phantom deadlocks occur due to false deadlocks
c. All of the above
d. None of these.

(xv) Which of the following deadlock detection method is more vulnerable to the
occurrence of false deadlocks?
a. Centralized deadlock detection
b. Hierarchical deadlock detection
c. Distributed deadlock detection
d. All of the above.

2. Consider the global wait-for graph in the following figure.

Site1 Site2

Tj Tj Tk

Ti Tk
Ti

Explain whether any deadlock situation has occurred or not.

3. Consider the same transactions of exercise 2 are executed with a deadlock prevention
method. Prove that the deadlock is prevented using both the preemptive and the non-
preemptive method. Assume arbitrarily transaction timestamp values and determine
which transactions are restarted in both cases.

179
4. Consider the local wait-for graphs at two different sites in the following figure.

T1 T2
T2 T3

T5 T5 T1

Site 1 Site 2

Explain whether any deadlock has occurred globally or not.

5. Consider the same transactions of exercise 4 are executed with a deadlock prevention
method. Prove that the deadlock is prevented using both the preemptive and the non-
preemptive method. Assume arbitrarily transaction timestamp values and determine
which transactions are restarted in both cases.

180