Transaction Overview

Transactions manage changes to multiple databases within a single application as a unit of work. That is, if you have an application that manages data within one or more databases, you can ensure that all changes in all databases are committed at the same time if they are managed within a transaction.

Transactions are described in terms of ACID properties, which are as follows:

• Atomic: all changes to the database made in a transaction are rolled back if any change fails.

• Consistent: the effects of a transaction take the database from one consistent state to another consistent state.

• Isolated: the intermediate steps in a transaction are not visible to other users of the database.

• Durable: when a transaction is completed (committed or rolled back), its effects persist in the database.

The JTA implementation, specified by Sun Microsystems, relies heavily on the JDBC 2.0 specification and XA architecture. The result is a complex requirement on applications in order to ensure that the transaction is managed completely across all databases. Sun Microsystems's specifies Java Transaction API (JTA) 1.0.1 and JDBC 2.0 on http://www.javasoft.com.

You should be aware of the following when using JTA within the Oracle8i environment:

• Global and Local Transactions

• Demarcating Transactions

• Transaction Context Propagation

• Two-Phase Commit

• Enlisting Resources

• JTA Limitations

Global and Local Transactions

Whenever your application connected to a database using JDBC or a SQL server, you were creating a transaction. However, the transaction involved only the single database and all updates made to the database were committed at the end of these changes. This is referred to as a local transaction.

A global transaction involves a complicated set of management objects--objects that track all of the objects and databases involved in the transaction. These global transaction objects--TransactionManager and Transaction--track all objects and resources involved in the global transaction. At the end of the transaction, the TransactionManager and Transaction objects ensure that all database changes are atomically committed at the same time.

Demarcating Transactions

A transaction is said to be demarcated, which means that each transaction has a definite start and stop point. For example, in an interactive tool such as SQL*Plus, each SQL DML statement implicitly begins a new transaction, if it is not already part of a transaction. A transaction ends when a SQL COMMIT or ROLLBACK statement is issued.

In a distributed object application, transactions are demarcated differently if the originator is the client or the server. Where the transaction originates defines the transaction as client-side demarcated or server-side demarcated. See "JTA Client-Side Demarcation" and "JTA Server-Side Demarcation" for more information.

The client or server object programmatically demarcates the transaction by executing the appropriate begin or commit methods. Explicit demarcation is discussed further in "JTA Client-Side Demarcation".

Note: The originating client or object that starts the transaction must also end the transaction with a commit or rollback. However, the originator can end the transaction in a different method than the originating method. For example, if the client begins the transaction, calls out to a server object, the client must end the transaction after the invoked method returns. The invoked server object cannot end the transaction.

Transaction Context Propagation

When you begin a transaction within either a client or a server instance, JTA denotes the originator in the transaction manager. As the transaction involves more objects and resources, the transaction manager tracks all of these objects and resources in the transaction and manages the transaction for these entities.

When an object calls another object, in order for the invoked object to be included in the transaction, JTA propagates the transaction context to the invoked object. Propagation of the transaction context is necessary for including the invoked object into the global transaction.

As shown in Figure 7-1, if the client begins a global transaction, calls a server object in the database, the transaction context is propagated to the server object. If the server object supports transactions, this object is attached to the transaction manager as involved in the global transaction. If this server object invokes another server object, within the same or a remote database, the transaction context is propagated to this object as well. This ensures that all objects that are supposed to be involved in the global transaction are tracked by the transaction manager.

Figure 7-1 Connection to an Object over IIOP

Enlisting Resources

Each resource, including databases, that you want managed in the global transaction must be enlisted. The Oracle8i JTA implementation automatically enlists all databases if you open a JDBC connection to the database within the context of a global transaction. The Oracle8i JDBC Developer's Guide contains more information on how to open a JDBC connection to a database within a transaction.

An object--client or server object--can only enlist a database within the global transaction through JDBC 2.0 methods within the DataSource object. The getConnection method must be invoked after the begin method of the UserTransaction object.

If your transaction involves more than one database, you must specify an Oracle8i database as the two-phase commit engine. See "Configuring Two-Phase Commit Engine" for more information.

Two-Phase Commit

One of the primary advantages for a global transaction is the number of objects and database resources managed as a single unit within the transaction. If your global transaction involves more than one database resource, you must specify a two-phase commit engine, which is an Oracle8i database designated to manage the changes to all databases within the transaction. The two-phase commit engine is responsible for ensuring that when the transaction ends, all changes to all databases are either totally committed or fully rolled back.

On the other hand, if your global transaction has multiple server objects, but only a single database resource, you do not need to specify a two-phase commit engine. The two-phase commit engine is required only to synchronize the changes for multiple databases. If you have only a single database, single-phase commit can be performed by the transaction manager.

Note: Your two-phase commit engine can be any Oracle8i database. It can be the database where your server object exists, or even a database that is not involved in the transaction at all. See "Configuring Two-Phase Commit Engine" for a full explanation of the two-phase commit engine setup.

Figure 7-2 shows three databases enlisted in a global transaction and another database that is designated as the two-phase commit engine. All databases, including the local database, are enlisted when a JDBC connection is opened after the global transaction starts. See "Enlisting Resources" for more information on database enlistment.

When the global transaction ends, the two-phase commit engine ensures that all changes made to the databases A, B, and the local are committed or rolled back simultaneously.

Figure 7-2 Two-Phase Commit for Global Transactions

JTA Limitations

The following are the portions of the JTA specification that Oracle8i does not support.

Nested Transactions

Nested transactions are not supported in this release. If you attempt to begin a new transaction before committing or rolling back any existing transaction, the transaction service throws a NotSupportedException exception.

Interoperability

The transaction services supplied with this release do not interoperate with other JTA implementations.

---