Databases Reference
In-Depth Information
Procedural Gateways
Procedural Gateways implement remote procedure calls (RPCs) to applications
built on non-Oracle data stores. The Gateway for APPC, the standard IBM protocol
for RPCs, is used when Oracle applications need procedural access to applications
built on CICS, DB2, IMS, VSAM, and other data stores on the mainframe and
applications that use SNA LU6.2 to communicate to the mainframe. The Oracle
Procedural Gateway for IBM WebSphere MQ allows Oracle-based applications to
exchange messages with applications that communicate via IBM MQ (message
queues).
Two-Phase Commit
One of the biggest issues associated with the use of distributed databases is the difficulty
of guaranteeing the same level of data integrity for updates to distributed databases.
Because a transaction that writes data to multiple databases must depend on a network
for the transmission of information, it is inherently more susceptible to lost information
than a single Oracle instance on a single machine. And since a transaction must guar‐
antee that all writes occur, this increased instability could adversely affect data integrity.
The standard solution for this problem is to use two message-passing phases as part of
a transaction commit; hence, the protocol used is referred to as a
two-phase commit
.
The initiating database serves as a global coordinator and first polls each of the partic‐
ipants to determine if they are ready and then sends transactional updates to them. In
the second phase, if all the participants are in agreement that the updates have properly
occurred, the changes are committed. If any of the nodes involved in the transaction
cannot verify receipt of the changes, the transactions are rolled back to their original
state on all the nodes.
For example, if a transaction is to span databases A, B, and C, in the first phase of the
commit operation, each of the databases is sent the appropriate transactional update. If
each of these databases acknowledges that it has received the update, the second phase
of the update executes the
COMMIT
command. By separating the transmission of the data
for the update from the actual
COMMIT
operation, a two-phase commit greatly decreases
the possibility of distributed data losing its integrity.
You can compare this approach to a single-phase update in which the
COMMIT
command
is sent along with the transactional update information. There is no way of knowing
whether the update ever reached all the databases, so any sort of interruption in the
delivery of the update to any of the machines would cause the data to be in an incon‐
sistent state. When a transaction involves more than one database, the possibility of the
loss of an update to one of the databases increases greatly; that, in turn, mandates the
use of the two-phase commit protocol. Of course, since the two-phase commit protocol
requires more messaging to be passed between databases, a two-phase commit can take
