This chapter discusses the Oracle Java Database Connectivity (JDBC) implementation of distributed transactions. These are multiphased transactions, often using multiple databases, which must be committed in a coordinated way. There is also related discussion of XA, which is a general standard, and not specific to Java, for distributed transactions.
This chapter discusses features of the JDBC 2.0 Optional Package, formerly known as the JDBC 2.0 Standard Extension application programming interface (API), which is available through the javax packages from Sun Microsystems.
For further introductory and general information about distributed transactions, refer to the Sun Microsystems specifications for the JDBC 2.0 Optional Package and the Java Transaction API (JTA).
Over view of Distributed Transactions
A distributed transaction. sometimes referred to as a global transaction. is a set of two or more related transactions that must be managed in a coordinated way. The transactions that constitute a distributed transaction might be in the same database, but more typically are in different databases and often in different locations. Each individual transaction of a distributed transaction is referred to as a transac tion branch .
For example, a distributed transaction might consist of money being transferred from an account in one bank to an account in another bank. You would not want either transaction committed without assurance that both will complete successfully.
In the JDBC 2.0 extension API, distributed transaction functionality is built on top of connection pooling functionality. This distributed transaction functionality is also built upon the open XA standard for distributed transactions. X A is part of the X/Open standard and is not specific to Java.
JDBC is used to connect to database resources. However, to include all changes to multiple databases within a transaction, you must use the JDBC connections within a JTA global transaction. The process of including database SQL updates within a transaction is referred to as enlisting a database resource.
The section covers the following topics:
Distributed Tran saction Components and Scenarios
In reading the remainder of the distributed transactions section, it will be helpful to keep the following points in mind:
A distributed transaction system typically relies on an external trans action manager, such as a software component that implements standard JTA functionality, to coordinate the individual transactions.
Many vendors offer XA-compliant JTA modules, including Oracle, which includes JTA in Oracle9 i Application Server and Oracle Application Server 10 g .
XA functionality is usually isolated from a client application, being implemented instead in a middle-tier environment, such as an application server.
In many scenarios, the application server and transaction manager will be together on the middle tier, possibly together with some of the application code as well.
Discussion throughout this section is intended mostly for middle-tier developers.
The term resour ce manager is often used in discussing distributed transactions. A resource manager is simply an entity that manages data or some other kind of resource. Wherever the term is used in this chapter, it refers to a database.
Using JTA functionality requires jta.jar to be in the CLASSPATH environment variable. This file is located at ORACLE_HOME /jlib. Oracle includes this file with the JDBC product. You
can also obtain it from the Sun Microsystems Web site, but it is advisable to use the version from Oracle, because that has been tested with the Oracle drivers.
Distributed Transaction Concepts
When you use XA functionality, the transaction manager uses XA resource instances to prepare and coordinate each transaction branch and then to commit or roll back all transaction branches appropriately.
XA functionality includes the following key components:
XA data sources
These are extensions of connection pool data sources and other data sources, and similar in concept and functionality.
There will be one XA data source instance for each resource manager that will be used in the distributed transaction. You will typically create XA data source instances in your middle-tier software.
XA data sources produce XA connections.
XA con nections
These are extensions of pooled connections and similar in concept and functionality. An XA connection encapsulates a physical database connection. Individual connection instances are temporary handles to these physical connections.
An XA connection instance corresponds to a single Oracle session, although the session can be used in sequence by multiple logical connection instances, as with pooled connection instances.
You will typically get an XA connection instance from an XA data source instance in your middle-tier software. You can get multiple XA connection instances from a single XA data source instance if the distributed transaction will involve multiple sessions in the same database.
XA connections produce OracleXAResource instances and JDBC connection instances.
XA res ources
These are used by a transaction manager in coordinating the transaction branches of a distributed transaction.
You will get one OracleXAResource instance from each XA connection instance, typically in your middle-tier software. There is a one-to-one correlation between OracleXAResource instances and XA connection instances. Equivalently, there is a one-to-one correlation between OracleXAResource instances and Oracle sessions.
In a typical scenario, the middle-tier component will hand off OracleXAResource instances to the transaction manager, for use in coordinating distributed transactions.
Because each OracleXAResource instance corresponds to a single Oracle session, there can be only a single active transaction branch associated with an OracleXAResource instance at any given time. However, there can be additional suspended transaction branches.
Each OracleXAResource instance has the functionality to start, end, prepare, commit, or roll back the operations of the transaction branch running in the session with which the OracleXAResource instance is associated.
The prepare step is the first step of a two-phase commit operation. The transaction manager will issue a PREPARE to each OracleXAResource instance. Once the transaction manager sees that the operations of each transaction branch have prepared successfully, it will issue a COMMIT to each OracleXAResource instance to commit all the changes.
Transactio n IDs
These are used to identify transaction branches. Each ID includes a transaction branch ID component and a distributed transaction ID component. This is how a branch is associated with a distributed transaction. All OracleXAResource instances associated with a given distributed transaction would have a transaction ID that includes the same distributed transaction ID component.
Start a loosely coupled transaction with transaction ID xid .
Switching Between Global and Local Transactions