Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Developer's Guide

- Previous: Chapter 11 Using the JDBC API for Database Access
- Next: Chapter 13 Using the Java Naming and Directory Interface

# Chapter 12 Using the Transaction Service

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

This chapter contains the following sections:

- Transaction Resource Managers

- Transaction Scope

- Configuring the Transaction Service

- Transaction Logging

For more information about the JavaTM Transaction API (JTA) and Java Transaction Service (JTS), see the Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Administration Guide and the following sites: `http://java.sun.com/products/jta/` and `http://java.sun.com/products/jts/`.

You might also want to read the chapter on transactions in the J2EE 1.4 Tutorial at `http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html`.

# Transaction Resource Managers

There are three types of transaction resource managers:

- Databases - Use of transactions prevents databases from being left in inconsistent states due to incomplete updates. For information about JDBC transaction isolation levels, see Using JDBC Transaction Isolation Levels.

  The Application Server supports a variety of JDBCTM XA drivers. For a list of the JDBC drivers currently supported by the Application Server, see the Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Release Notes. For configurations of supported and other drivers, see Configurations for Specific JDBC Drivers.

- Java Message Service (JMS) Providers - Use of transactions ensures that messages are reliably delivered. The Application Server is integrated with Sun Java System Message Queue, a fully capable JMS provider. For more information about transactions and the JMS API, see Chapter 14, Using the Java Message Service.

- J2EETM Connector Architecture (CA) components - Use of transactions prevents legacy EIS systems from being left in inconsistent states due to incomplete updates. For more information about connectors, see Chapter 9, Developing Connectors.

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

Note –

In the Application Server, the transaction manager is a privileged interface. However, applications can access `UserTransaction`. For more information, see Naming Environment for J2EE Application Components.

# 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 J2EE application.

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

- In the JDBC connection pool configuration, the DataSource class does not implement the `javax.sql.XADataSource` interface.

- The Global Transaction Support box is not checked, or the Resource Type setting does not exist or is not set to `javax.sql.XADataSource`.

A transaction remains local if the following conditions remain true:

- One and only one non-XA resource is used. If any additional non-XA resource is used, the transaction is aborted.

- No transaction importing or exporting occurs.

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.

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.

- Oracle thin driver - The `XAResource.recover` method repeatedly returns the same set of in-doubt Xids regardless of the input flag. According to the XA specifications, the Transaction Manager initially calls this method with TMSTARTSCAN and then with TMNOFLAGS repeatedly until no Xids are returned. The `XAResource.commit` method also has some issues.

  To disable the Application Server workaround, set the `oracle-xa-recovery-workaround` property value to `false`. For details about how to set this property, see Configuring the Transaction Service.

Note –

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

# Configuring the Transaction Service

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

- To configure the transaction service using the Administration Console, open the Transaction Service component under the relevant configuration. For details, see the Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Administration Guide.

- To configure the transaction service, use the `asadmin set` command to set the following attributes:

      server.transaction-service.automatic-recovery = false
      server.transaction-service.heuristic-decision = rollback
      server.transaction-service.keypoint-interval = 2048
      server.transaction-service.retry-timeout-in-seconds = 600
      server.transaction-service.timeout-in-seconds = 0
      server.transaction-service.tx-log-dir = domain-dir/logs

  You can also set these properties:

      server.transaction-service.property.oracle-xa-recovery-workaround = false
      server.transaction-service.property.disable-distributed-transaction-logging = false
      server.transaction-service.property.xaresource-txn-timeout = 600
      server.transaction-service.property.pending-txn-cleanup-interval = 60
      server.transaction-service.property.use-last-agent-optimization = true

  You can use the `asadmin get` command to list all the transaction service attributes and properties. For details, see the Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Reference Manual.

# 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:

- Set the location of the transaction log files using the Transaction Log Location setting in the Administration Console, or set the `tx-log-dir` attribute using the `asadmin set` command.

- Turn off transaction logging by setting the `disable-distributed-transaction-logging` property to `true`. Do this only if performance is more important than transaction recovery.

- Previous: Chapter 11 Using the JDBC API for Database Access
- Next: Chapter 13 Using the Java Naming and Directory Interface

- © 2010, Oracle Corporation and/or its affiliates