Not For Publication   
Glassfish Review Draft
Sun Java System Application Server Platform Edition 9.0 Developer's Guide 
Previous     Contents     Index     Next
Chapter 15

Using the Transaction Service

The Java EE platform provides several abstractions that simplify development of dependable transaction processing for applications. This chapter discusses Java EE transactions and transaction support in the Sun Java System Application Server.

This chapter contains the following sections:

For more information about the Java™ Transaction API (JTA) and Java™ Transaction Service (JTS), see the Sun Java System Application Server Platform Edition 9.0 Administration Guide and the following sites: and

You might also want to read the chapter on transactions in the Java EE 5 Tutorial at

Transaction Resource Managers

There are three types of transaction resource managers:

For details about how transaction resource managers, the transaction service, and applications interact, see the Sun Java System Application Server Platform Edition 9.0 Administration Guide.

Transaction Scope

A local transaction involves only one non-XA resource and requires that all participating application components execute within one process. Local transaction optimization is specific to the resource manager and is transparent to the Java EE application.

In the Application Server, a JDBC resource is non-XA if it meets any of the following criteria:

A transaction remains local if the following conditions remain true:

Transactions that involve multiple resources or multiple participant processes are distributed or global transactions. A global transaction can involve one non-XA resource if last agent optimization is enabled. Otherwise, all resourced must be XA. The use-last-agent-optimization property is set to true by default. For details about how to set this property, see Configuring the Transaction Service.

If only one XA resource is used in a transaction, one-phase commit occurs, otherwise the transaction is coordinated with a two-phase commit protocol.

A two-phase commit protocol between the transaction manager and all the resources enlisted for a transaction ensures that either all the resource managers commit the transaction or they all abort. When the application requests the commitment of a transaction, the transaction manager issues a PREPARE_TO_COMMIT request to all the resource managers involved. Each of these resources can in turn send a reply indicating whether it is ready for commit (PREPARED) or not (NO). Only when all the resource managers are ready for a commit does the transaction manager issue a commit request (COMMIT) to all the resource managers. Otherwise, the transaction manager issues a rollback request (ABORT) and the transaction is rolled back.

Configuring the Transaction Service

You can configure the transaction service in the Application Server in the following ways:

Accessing the Transaction Manager and UserTransaction

You can access the Application Server transaction manager, a javax.transaction.TransactionManager implementation, using the JNDI subcontext java:appserver/TransactionManager. You can also access java:comp/UserTransaction. For more information, see Naming Environment for Java EE Application Components.

Transaction Logging

The transaction service writes transactional activity into transaction logs so that transactions can be recovered. You can control transaction logging in these ways:

Recovery Workarounds

The Application Server provides workarounds for some known issues with the recovery implementations of the following JDBC drivers. These workarounds are used unless explicitly disabled.

Note - These workarounds do not imply support for any particular JDBC driver.

Previous     Contents     Index     Next