12.2 Two-Phase Commits
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 because a transaction must guarantee 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 main database first polls each of the participants to determine
if they are ready; if they are, the transactional updates are
tentatively sent to them. In the second phase, if all the
participants are in agreement that the messages have properly been
received, 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.
For example, if a transaction is to span databases on machines 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 machines acknowledges that it has received the update, the
second phase of the update executes the COMMIT statement.
You can compare this approach with a single-phase update in which the
COMMIT statement is sent along with the transactional update
information. There is no way of knowing whether the update ever
reached all the machines, so any sort of interruption in the delivery
of the update to any of the machines would cause the data to be in an
inconsistent state. When a transaction involves more than one
machine, the possibility of the loss of an update to one of the
machines increases greatly, which, in turn, mandates the use of the
two-phase commit protocol. Of course, because the two-phase commit
protocol requires more messaging to be passed between machines, a
two-phase commit can take longer than a standard commit; however, the
corresponding gain in all-important data integrity more than makes up
for the decrease in performance.
12.2.1 Transaction Processing Monitors
In
1991, X/Open defined an open systems standard interface through which
transaction processing (TP) monitors could communicate with
XA-compliant resource managers (the role of the Oracle RDBMS and
other XA-compliant databases in the X/Open model). Several popular
TP
monitors that support XA have appeared, including
BEA
Tuxedo and IBM's CICS and Encina (primarily used on
IBM AIX or Windows and bundled today in
IBM
TXSeries within WebSphere).
Oracle added an Oracle Manager for
Microsoft Transaction Server (MTS) to
Oracle8i for Windows NT. With this option,
Oracle can provide a database solution where MTS works as an
application server for COM-based distributed
applications. Further enhancements in
Oracle9i enabled the database to participate as
a transaction resource manager in MTS environments and, in Release 2
of Oracle9i, added .NET support, enabling .NET transactional
applications to use Oracle as a resource manager.
We have mentioned TP monitors in previous chapters in connection with
their role in online transaction processing. Among their other
duties, TP monitors assure that transactions between multiple
applications and resources complete properly. As noted previously,
Oracle provides its own two-phase commit protocol for distributed
transactions, one of the early primary uses of a TP monitor.
Standalone TP monitors are used less frequently today for workload
management (see Figure 12-2), as this capability is now built into
middle-tier applications. Examples of why TP monitors might still be
used with Oracle databases include:
Migration
of legacy applications (usually originally written using CICS and
COBOL for a mainframe) to CICS on Unix or Windows NT Two-phase commits between Oracle and other XA-compliant databases Three-tier implementations for ActiveX/DCOM applications deployed on
Windows platforms (using MTS)
| 
No comments:
Post a Comment