Overview of JTA

This is a brief overview of XA concepts.

About TimesTen JTA

The TimesTen implementation of the JTA interfaces, supported only in TimesTen Classic, is intended to enable Java applications, application servers, and transaction managers to use TimesTen resource managers in distributed transaction processing (DTP) environments.

The TimesTen implementation is supported for use with the Oracle WebLogic Server.

Refer to the following locations for additional information.

As TimesTen JTA is built on top of the TimesTen implementation of the X/Open XA standard, much of the discussion in this chapter is in terms of underlying XA features. You can also refer to Distributed Transaction Processing: XA in Oracle TimesTen In-Memory Database C Developer's Guide.

Tip:

  • The TimesTen XA implementation does not work with cache. The start of any XA transaction fails if the cache agent is running.

  • You cannot execute an XA transaction if replication is enabled.

  • Do not execute DDL statements within an XA transaction.

X/Open DTP Model

There are interfaces defined by the X/Open DTP model.

Figure 4-1 illustrates the interfaces defined by the X/Open DTP model.

Figure 4-1 Distributed Transaction Processing Model

Description of Figure 4-1 follows
Description of "Figure 4-1 Distributed Transaction Processing Model"

The TX interface is what applications use to communicate with a transaction manager. The figure shows an application communicating global transactions to the transaction manager. In the DTP model, the transaction manager breaks each global transaction down into multiple branches and distributes them to separate resource managers for service. It uses the JTA interface to coordinate each transaction branch with the appropriate resource manager.

In the context of TimesTen JTA, the resource managers can be a collection of TimesTen databases, or databases in combination with other commercial databases that support JTA.

Global transaction control provided by the TX and JTA interfaces is distinct from local transaction control provided by the native JDBC interface. It is generally best to maintain separate connections for local and global transactions. Applications can obtain a connection handle to a TimesTen resource manager to initiate both local and global transactions over the same connection.

Two-Phase Commit

In a JTA implementation, the transaction manager commits the distributed branches of a global transaction by using a two-phase commit protocol.

  1. In phase 1, the transaction manager directs each resource manager to prepare to commit, which is to verify and guarantee it can commit its respective branch of the global transaction. If a resource manager cannot commit its branch, the transaction manager rolls back the entire transaction in phase 2.

  2. In phase 2, the transaction manager either directs each resource manager to commit its branch or, if a resource manager reported it was unable to commit in phase 1, rolls back the global transaction.

Note the following optimizations.

  • If a global transaction is determined by the transaction manager to have involved only one branch, it skips phase 1 and commits the transaction in phase 2.

  • If a global transaction branch is read-only, where it does not generate any transaction log records, the transaction manager commits the branch in phase 1 and skips phase 2 for that branch.

Note:

The transaction manager considers the global transaction committed if and only if all branches successfully commit.