Oracle7 Server Distributed Systems Volume I: Distributed Data
Updates in a Distributed Environment
Distributed updates add several levels of complexity to a distributed system. The fact that multiple users are sharing and accessing data that exists at many sites rather that at a single site, adds the following considerations when these users attempt to update that data:
- replication (update propagation)
- transaction recovery management
Replication
In a distributed system, a data object can be represented at many sites. Making sure that updates to any representative at any of the sites are propagated to all other sites is the responsibility of Oracle7's
replication mechanisms.
The Oracle Server provides several methods for data replication.
A snapshot is a full copy of a table, or a subset of a table, that reflects a recent state of a master table (the table on the node that you designate as the master node). A snapshot is defined by a distributed query that references one or more master tables, views, or, with certain limitations, other snapshots.
Read-only snapshots can be used for queries only and are the simplest form of replication. They are typically used for systems in which many sites need to query data that are updated only by one site..
Updatable snapshots can reflect local updates and therefore improve response time by avoiding network traffic. However, there must be a mechanism that ensures that the local updates are not lost when the snapshot is refreshed from the master table.
Oracle's symmetric replication facility provides that mechanism. It allows multiple copies of data to be maintained at different sites in a distributed system.
See Oracle7 Server Distributed Systems, Volume II for information about the concepts behind replication and how to implement replication in your distributed system.
Concurrency Control
In a distributed system, there is the strong potential for more than one user to be concurrently executing transactions that update the same data and produce incorrect results. Oracle provides locking mechanisms to handle multiuser access to the same data.
See Chapter 10, "Data Concurrency", of the Oracle7 Server Concepts manual for more information.
In a distributed system, there is another level of complexity. A situation called global deadlock can occur. For example, transaction T1 has a lock on object A in San Francisco and requests a lock on object B in Dallas, and transaction T2 has a lock on object B in Dallas and requests a lock on object A in San Francisco. This series of events would cause both transactions to go into wait states.
In Oracle distributed transactions, local deadlocks are detected by analyzing a "waits for" graph, and global deadlocks are detected by a time-out. Once detected, non-distributed and distributed deadlocks are handled by the database and application in the same way.
Distributed Transaction Management
All participants (nodes) in a distributed transaction should be unanimous as to the action to take on that transaction. That is, they should either all commit or rollback.
Oracle uses a prepare/commit mechanism to ensure that all participants in the distributed transaction are "on the same track".
Briefly, a prepare/commit mechanism works this way (more detailed instructions for implementing prepare/commit are in
following sections):
In a prepare/commit system, the initiating node is called the global coordinator. When this site receives a commit request from an update transaction, it asks all participants in the distributed system to prepare (to promise to commit or rollback the transaction, even if there is a failure). The participating sites will reply that they are either prepared to commit or not.
If the global coordinator receives a "prepared to commit" message from all the participating sites, it broadcasts a commit command to all sites. If even one site has replied that it is not prepared to commit, the global coordinator will abort the transaction and send out a rollback (or undo) command.