7.4. XA Transactions

7.4.1. Overview of XA Distributed Transaction Processing
7.4.2. Requirements for using Kodo with XA transactions
7.4.3. Configuring Kodo to utilize XA transactions

7.4.1. Overview of XA Distributed Transaction Processing

The X/Open Distributed Transaction Processing (X/Open DTP) model, designed by Open Group (a vendor consortium), defines a standard communication architecture that provides the following:

  • Concurrent execution of applications on shared resources

  • Coordination of transactions across applications

  • Components, interfaces, and protocols that define the architecture and provide portability of applications

  • Atomicity of transaction systems

  • Single-thread control and sequential function-calling

The X/Open DTP XA standard defines the application programming interfaces that a resource manager uses to communicate with a transaction manager. The XA interfaces enable resource managers to join transactions, to perform two-phase commit, and to recover in-doubt transactions following a failure.

7.4.2. Requirements for using Kodo with XA transactions

Kodo JDO Enterprise Edition support XA-compliant transactions when used in a properly configured managed environment. The following components are required:

  • A managed environment that provides an XA compliant TransactionManager. Examples of this are application servers such as JBoss and WebLogic.

  • Instances of a javax.sql.XADataSource for each of the datasources that Kodo will use for communication.

7.4.3. Configuring Kodo to utilize XA transactions

In order for Kodo to participate in a distributed transaction, the following configuration tasks needs to be accomplished:

  • Configure an instance of javax.sql.XADataSource to be available from JNDI. The mechanism for configuring data sources is specific to each application server; consult your application server's documentation for details on accomplishing this.

    The remainder of this section will assume that you have bound an instance of an Oracle XADataSource under the name java:/OracleXASource.

  • Configure a separate instance of javax.sql.DataSource to be available from JNDI. Kodo needs to have access to a transactional data source that will not be enlisted in an XA transaction for non-transactional access. This is required for things like obtaining database sequence numbers for datastore identity, which should not be part of Kodo's transaction.

    The remainder of this section will assume that you have bound an instance of an Oracle DataSource under the name java:/OracleSource.

  • Kodo needs to be aware that it should follow the contracts of a distributed transaction. This is done by specifying the TransactionMode attribute to be "xa".

  • Kodo must be configured to use the two named data sources. Set the ConnectionFactoryName property to be java:/OracleXASource and ConnectionFactory2Name to java:/OracleSource.

For example, if configuring Kodo via a properties file, the following properties would be used:
javax.jdo.option.ConnectionFactoryName=java:/OracleXASource
javax.jdo.option.ConnectionFactory2Name=java:/OracleSource
com.solarmetric.kodo.TransactionMode=xa