Database Reference
In-Depth Information
Site A
Site B
T5
TO
T3
T3
T4
T2
TO
T2
T1
Figure 18-22
Local wait-for graphs with TO transaction.
Site B
T3
T4
T2
TO
Figure 18-23
Updated local wait-for graph showing deadlock condition.
a certainty. The deadlock detection algorithm in the distributed scheme must ascer-
tain whether a deadlock really exists. Let us see how the algorithm works.
Consider the local wait-for graphs shown in Figure 18-22. At site A, the deadlock
detection algorithm senses a cycle containing a TO transaction. On analysis, a
determination is made that T3 is waiting for a resource at site B. Site A sends
a message to site B with information about the cycle. Site B updates its wait-for
graph with the information from site A and creates the wait-for cycle shown in
Figure 18-23.
The updated wait-for graph at site B displays a cycle without TO as part of it,
indicating a definite deadlock. The technique described here enables you to under-
stand the general idea behind the distributed scheme of wait-for graphs just enough
for the scope of our study here.
Distributed Recovery
As expected, recovery from failures has added dimensions of complexity. A dis-
tributed database environment faces new kinds of failures not found in centralized
systems. One or more remote sites may go down, and these may be the sites at which
subqueries or subtransactions are executing. The DDBMS must continue to operate
the other sites while the failed sites are brought back up. The communication
network forms a major component in the distributed system, and the communica-
tions network, completely or in part, may fail and cause interruptions.
When the recovery manager software completes recovery, the distributed data-
base, all parts of it and the replicas, must be left in a consistent and correct state. In
Search WWH ::
Custom Search