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

copies at other sites are secondary copies. Only the primary copy is updated
synchronously. Transactions cannot update secondary copies. The primary site
propagates the updates to secondary copies at a later time. This method
reduces the type of traffic at the central site in synchronous replication. Still,
the primary site is subject to heavy traffic. Another shortcoming of this method
relates to the fact that only data at the primary site are absolutely correct at
all times; the other sites are constantly being synchronized with the primary
site.
4. Update at multiple primary sites
All or most of the sites holding replicated copies are designated as primary
sites. Each of these designated sites is the primary site for some portion of the
database being replicated. By spreading the responsibility around, the traffic
at each primary site becomes reduced and manageable. However, this method
adds another task to the transaction—for each update, the primary site must
first be identified before the transaction can proceed.
Concurrency Control
In the above discussion on transaction processing, we concentrated on the execu-
tion of a single transaction and how the execution gets coordinated across partici-
pating sites. Now let us introduce other transactions and examine concurrency
control in a distributed database environment. Concurrency control becomes more
complex in a distributed database environment because two or more concurrent
transactions may be attempting to simultaneously update two or more copies of the
same database object. Therefore, a concurrency control technique must take into
account the fragmentation, replication, and data allocation schemes and also how
replicated data are being kept synchronized.
Recall the concept of serializability discussed when we were dealing with con-
currency control in a centralized database system. If two transactions execute one
after the other, this is serial execution. If the effects on the database produced by
two concurrent transactions are the same as though they executed serially, then the
concurrency control techniques ensure serializability. Locking mechanisms in dis-
tributed database systems are also based on the same principle. The concurrency
control protocol dictates how locks are obtained and released. In our previous
discussion on transaction processing, we ignored locking and unlocking issues and
confined the discussion to propagation of updates. Now let us examine lock man-
agement in a distributed database environment. Which site manages the locks?
Lock Management Locking and unlocking functions are generally handled in
the ways indicated below. As you will note, each option has its advantages and
disadvantages.
Locking at primary site. One site is chosen as a primary, central site where locks
are held. The lock manager at this site is responsible for all locking and unlocking
functions. This is a straightforward option. However, transaction processing at
any site will halt if the primary site is down. The whole system is dependent on a
particular site being operational.