DISTRIBUTED DATABASE SYSTEMS - Database Design and Development: An Essential Guide for IT Professionals - page 578

Locking primary copy. One of the replicated copies of a database object is selected
as the primary copy. Locking and unlocking of any copy of the object is the respon-
sibility of the lock manager at the site where the primary copy is held. In this option,
if the primary copy is held in one site and the locking is for a copy at a different
site, the processing of the relevant transaction requires it to communicate not just
to the site where the read or update is intended to take place, but also to the site
where the primary copy is held. However, all transaction processing need not stop
if one site goes down.
Locking distributed copies. The lock manager at each site is responsible for locking
and unlocking of all database objects at that site. When a transaction wants to lock
a copy of a database object, it need not communicate with another site just for the
locking and unlocking.
Deadlock Resolution Chapter 15, covering the important topic of data integrity,
discusses deadlock resolution in a centralized database environment. In that
chapter, you learned about the two methods for resolving deadlocks as part of
concurrency control: deadlock prevention and deadlock detection.
Recall that deadlock prevention, a more involved technique, is generally applic-
able to environments where transactions run long and the number of update trans-
actions far exceeds the number of queries that contain read-only operations. A
typical database environment used for operating an organization's business
generally has an even mixture of update transactions and read-only queries.
Furthermore, not too many conflicts arise among concurrent transactions because
the applications are streamlined and updates are orderly.
Deadlock detection, on the other hand, is simpler to implement. One of the
contending transactions is forced out, and the deadlock gets resolved. The
DBMS uses a wait-for graph to detect a deadlock situation and aborts one of
the transactions, based on defined criteria, if a deadlock is sensed. You have studied
how the DBMS maintains wait-for graphs and uses the technique to detect dead-
locks. The other method used by DBMSs to detect deadlocks relies on a timeout
technique.
In practice, deadlock detection with wait-for graphs is widely used. In Chapter
15, we discussed this deadlock detection scheme with wait-for graphs for the
centralized database system. Now let us reexamine the scheme and note its applic-
ability to the distributed database environment.
In a centralized database environment, there is only one site for the database and
the wait-for graph is maintained and used at that site. Transactions execute at only
one site. However, in a distributed database environment, transactions operate on
database objects at multiple sites. When you inspect the concurrent transactions
executing at a single site, some of these emanated from other sites and the rest
were initiated locally. Maintenance of wait-for graphs—where and how—poses the
greatest challenge.
Let us begin with the idea of each site maintaining a wait-for graph. As you know,
the nodes of the graph represent all transactions, both local and otherwise, waiting
on local database objects held by other transactions. Assuming a two-site distrib-
uted database system, Figure 18-19 presents an example of wait-for graphs at the
two sites.