Oracle7 Server Distributed Systems Volume I: Distributed Data

Contents Index Home Previous Next

XA Library-Related Information

General Information about the Oracle XA Library

For preliminary reading and additional reference information regarding the Oracle XA library, see the following documents:

Additional Information: For information on library linking filenames, see your Oracle operating system- specific documentation.

README.doc

A README.doc file is located in a directory specified in your Oracle operating system-specific documentation and describes changes, bugs, or restrictions in the Oracle XA library for your platform since the last version.

Basic Architecture

The Oracle XA library is an external interface that allows global transactions to be coordinated by a transaction manager other than the Oracle7 Server. This allows inclusion of non-Oracle7 Server entities called resource managers (RM) in distributed transactions.

The Oracle XA library conforms to the X/Open Distributed Transaction Processing (DTP) software architecture's XA interface specification.

For a general overview of XA, including basic architecture, see X/Open CAE Specification - Distributed Transaction Processing: The XA Specification.

You can obtain a copy of this document by requesting X/Open Document No. XO/CAE/91/300 or ISBN 1 872630 24 3 from:

X/Open Company, Ltd. 1010 El Camino Real, Suite 380 Menlo Park, CA 94025 U.S.A.

X/Open Distributed Transaction Processing (DTP)

The X/Open DTP architecture defines a standard architecture or interface that allows multiple application programs to share resources, provided by multiple, and possibly different, resource managers. It coordinates the work between application programs and resource managers into global transactions.

Figure 7 - 1 illustrates a possible X/Open DTP model.

Figure 7 - 1. One Possible DTP Model

A resource manager (RM) controls a shared, recoverable resource that can be returned to a consistent state after a failure. For example, Oracle7 Server is an RM and uses its redo log and undo segments to return to a consistent state after a failure. An RM provides access to shared resources such as a database, file systems, printer servers, and so forth.

A transaction manager (TM) provides an application program interface (API) for specifying the boundaries of the transaction and manages the commit and recovery procedures.

Normally, Oracle7 Server acts as its own TM and manages its own commit and recovery. However, using a standards-based TM allows Oracle7 Server to cooperate with other heterogeneous RMs in a single transaction.

A TM is usually a component provided by a transaction processing monitor (TPM) vendor. The TM assigns identifiers to transactions, and monitors and coordinates their progress. It uses Oracle XA library subroutines to tell Oracle7 Server how to process the transaction, based on its knowledge of all RMs in the transaction. You can find a list of the XA subroutines and their descriptions later in this section.

An application program (AP) defines transaction boundaries and specifies actions that constitute a transaction. For example, an AP can be a precompiler or OCI program. The AP operates on the RM's resource through the RM's native interface, for example SQL. However, it starts and completes all transaction operations via the transaction manager through an interface called TX. The AP itself does not directly use the XA interface.

Note: The naming conventions for your TX interface and associated subroutines are vendor-specific, and may differ from those used here. For example, you may find that the tx_open call is referred to as tp_open on your system. To check on terminology, see the documentation supplied with your transaction processing monitor.

Transaction Recovery Management

The Oracle XA library interface follows the two-phase commit protocol, consisting of a prepare phase and a commit phase, to commit transactions.

In phase one, the prepare phase, the TM asks each RM to guarantee the ability to commit any part of the transaction. If this is possible, then the RM records its prepared state and replies affirmatively to the TM. If it is not possible, the RM may roll back any work, reply negatively to the TM, and forget any knowledge about the transaction. The protocol allows the application, or any RM, to roll back the transaction unilaterally until the prepare phase is complete.

In phase two, the commit phase, the TM records the commit decision. Then the TM issues a commit or rollback to all RMs which are participating in the transaction. Note that a TM can issue a commit for an RM only if all RMs have replied affirmatively to phase one.

Compatibility Issues

The XA library supplied with release 7.3 can be used only against a release 7.3 server. You must use the release 7.2 XA library against a 7.2 server.

Oracle XA Library Interface Subroutines

The Oracle XA library subroutines allow a TM to instruct Oracle7 Server what to do about transactions. Generally, the TM must "open" the resource (using xa_open). Typically, this will result from the AP's call to tx_open. Some TMs may call xa_open implicitly, when the application begins. Similarly, there is a close (using xa_close) that occurs when the application is finished with the resource. This may be when the AP calls tx_close or when the application terminates.

There are several other tasks the TM instructs the RMs to do. These include among others:

XA Library Subroutines

The following XA Library subroutines are available:

xa_open connect to the resource manager
xa_close disconnect from the resource manager
xa_start start a new transaction and associate it with the given transaction ID (XID), or associate the process with an existing transaction
xa_end disassociate the process from the given XID
xa_rollback roll back the transaction associated with the given XID
xa_prepare prepare the transaction associated with the given XID. This is the first phase of the two-phase commit protocol.
xa_commit commit the transaction associated with the given XID. This is the second phase of the two-phase commit protocol.
xa_recover retrieve a list of prepared, heuristically committed or heuristically rolled back transactions
xa_forget forget the heuristic transaction associated with the given XID
xa_complete wait for completion of an asynchronous operation
In general, the AP does not need to worry about these subroutines except to understand the role played by the xa_open string.

Transaction Processing Monitors (TPMs)

Under UNIX, for example, a transaction processing monitor (TPM) coordinates the flow of transaction requests between the client processes that issue requests and the back-end servers that process them. Basically, a TPM coordinates transactions that require the services of several different types of back-end processes, such as application servers and resource managers that are distributed over a network.

The TPM synchronizes any commits and rollbacks required to complete a distributed transaction. The transaction manager (TM) portion of the TPM is responsible for controlling when distributed commits and rollbacks take place. Thus, if a distributed application program is written to take advantage of a TPM, the TM portion of the TPM is responsible for controlling the two-phase commit protocol. The RMs enable the TMs to do this.

Because the TM controls distributed commits or rollbacks, it must communicate directly with Oracle (or any other resource manager). It communicates through the Oracle XA library interface.

Required Public Information

As a resource manager, Oracle is required to publish the following information:

xa_switch_t structure The Oracle Server xa_switch_t structure name is xaosw. This structure contains entry points and other information for the resource manager.
xa_switch_t resource mgr The Oracle Server resource manager name within the xa_switch_t structure is Oracle_XA.
close string The close string used by xa_close () is ignored and may be null.
open string The format of the open string used by xa_open () is described in detail in the section titled "Developing and Installing Applications that use the XA Libraries" [*].
libraries Libraries needed to link applications using Oracle XA have operating system-specific names. In general, it is similar to linking an ordinary precompiler or OCI program except with one additional library ($ORACLE_HOME/lib/libxa.a), and any TPM-specific libraries.
See your Oracle operating system-specific documentation and the Oracle XA README.doc file to find the correct library name.
Use of the Oracle XA library restricts the use of SQL to connect to and disconnect from the database and to perform transaction operations. These restrictions are described in "Interfacing to Precompilers and OCIs" [*].
requirements You must have purchased and installed the distributed database option.

Additional XA Issues

Note the following additional information about Oracle XA issues:

DDL statements Oracle applications in global transactions may not perform DDL statements (like CREATE TABLE, DROP TABLE, CREATE INDEX) because they force a commit of pending work.
global and local transactions When an application uses the XA library to connect to the Oracle Server, that application can only operate on global transactions. The Oracle Server does not allow local transactions when it is using XA.
transaction branches Oracle Server transaction branches within the same global transaction share locks in a tightly coupled manner. However, if the branches are on different instances when running Oracle Parallel Server, then they are loosely coupled.
read-only Oracle Server supports the read-only optimization.
association migration Oracle Server does not support association migration (a means whereby a transaction manager may resume a suspended branch association in another branch).
dynamic registration The optional XA feature dynamic registration is not supported.
asynchronous calls The optional XA feature asynchronous XA calls is not supported.

Contents Index Home Previous Next