Chapter 10 Transactions

Application Server handles transactions based on Java EE specification requirements. It supports some extra features that are exposed and can be changed in the Administration Console. This chapter discusses the following:

• About Transactions

• Configuring Transaction Management

About Transactions

The following subsections explain what are transactions and how transaction processing is handled in Java EE.

• What Is a Transaction?

• Transactions in Java EE Technology

• Workarounds for Specific Databases

What Is a Transaction?

A transaction is a series of discreet actions in an application that must all complete successfully or else all the changes in each action are backed out. For example, to transfer funds from a checking account to a savings account is a transaction with the following steps:

1. Check to see if the checking account has enough money to cover the transfer.

2. If there’s enough money in the checking account debit the amount from the checking account.

3. Credit the money to the savings account.

4. Record the transfer to the checking account log.

5. Record the transfer to the savings account log.

If any of these steps fails, all changes from the preceding steps must be backed out, and the checking account and savings account must be in the same state as they were before the transaction started. This event is called a rollback. If all the steps complete successfully, the transaction is in a committed state. Transactions end in either a commit or a rollback.

Transactions in Java EE Technology

Transaction processing in Java EE technology involves the following five participants:

• Transaction Manager

• Application Server

• Resource Manager

• Resource Adapter

• User Application

Each of these entities contributes to reliable transaction processing by implementing the different APIs and functionality, discussed below:

• The Transaction Manager provides the services and management functions required to support transaction demarcation, transactional resource management, synchronization, and transaction context propagation.

• The Application Server provides the infrastructure required to support the application runtime environment that includes transaction state management.

• The Resource Manager (through a resource adapter) provides the application access to resources. The resource manager participates in distributed transactions by implementing a transaction resource interface used by the transaction manager to communicate transaction association, transaction completion, and recovery work. An example of such a resource manager is a relational database server.

• A Resource Adapter is a system level software library that is used by the application server or client to connect to a Resource Manager. A Resource Adapter is typically specific to a Resource Manager. It is available as a library and is used within the address space of the client using it. An example of such a resource adapter is a JDBC driver.

• A User Application developed to operate in an application server environment may use transactional data sources. The application may use declarative transaction attribute settings for enterprise beans or explicit programmatic transaction demarcation.

Workarounds for Specific Databases

The Application Server provides workarounds for some known issues with the recovery implementations of the following JDBC drivers. These workaround 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 a property, see the Admin Console online help.

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

Configuring Transaction Management

The Application Server handles transactions based on the settings in the Admin Console.

This section explains how to configure transaction settings:

• Configuring Application Server to Recover Transactions

• Setting a Transaction Timeout Value

• Specifying the Transaction Logs

• Setting the Keypoint Interval

For additional information about transactions, see these sections:

• What Is a Transaction?

• Transactions in Java EE Technology

Configuring Application Server to Recover Transactions

Transactions might be incomplete either because the server crashed or a resource manager crashed. It is essential to complete these stranded transactions and recover from the failures. Application Server is designed to recover from these failures and complete the transactions upon server startup.

While performing the recovery, if some of the resources are unreachable the server restart may be delayed as it tries to recover the transactions.

When the transaction spans across servers, the server that started the transaction can contact the other servers to get the outcome of the transactions. If the other servers are unreachable, the transaction uses the Heuristic Decision field to determine the outcome.

For Oracle, the database user for an XA datasource requires necessary permissions to be able to recover any transactions after Application Server has crashed and has been restarted. The Oracle permissions required on various tables for transaction recovery are:

• SELECT permissions on DBA_PENDING_TRANSACTIONS, PENDING_TRANS$, DBA_2PC_PENDING and DBA_2PC_NEIGHBORS tables

• EXECUTE permissions on DBMS_SYSTEM table

To configure Application Server to recover transactions using the Administration Console, select Configuration>Transaction Service. The Transaction Service page displays the general transaction service settings.

To enable the recovery of incomplete transactions, check the Recover box in the On Restart field. When a resource becomes unreachable during critical points in the transaction Commit protocol, transactions may not complete and remain in transaction log file. If this check box is marked, the server attempts to recover stranded transactions upon server restart. If the involved resources remain unreachable, this may delay server restart. This checkbox is not marked by default. Note that if automatic recovery is not enabled, only 2048 XA transactions are recoverable. Also see the use of the Keypoint Interval as described below.

Modify values of other fields as necessary. In the Keypoint Interval (transactions) field, specify the number of transactions between keypoint operations in the log. Keypoint operations reduce the size of the transaction log file by removing entries for completed transactions and compressing the file. A larger value for this attribute results in a larger transaction log file, but fewer keypoint operations mean a potentially better performance. A smaller value (for example, 100) results in smaller log files, but slightly reduced performance due to the greater frequency of keypoint operations.

Detailed steps for doing this are provided in the Administration Console Online Help.

Setting a Transaction Timeout Value

By default, the server does not time out a transaction. That is, the server waits indefinitely for a transaction to complete. If you set a timeout value for transactions, if a transaction isn’t completed within the configured time, the Application Server rolls back the transaction.

To set transaction timeout value using the Administration Console, select Configuration>Transaction Service. The Transaction Service page displays the general transaction service settings. Enter the number of seconds before the transaction times out, in the Transaction Timeout field. The default value of Transaction Timeout is 0 seconds. This disables transaction timeouts.

Specifying the Transaction Logs

The transaction log records the information about each transaction in order to maintain the data integrity of the resources involved and to recover from failures. Transaction logs are kept in the tx subdirectory of the directory specified by the Transaction Log Location field. These logs are not human readable.

To set the location of the transaction logs using the Administration Console, select Configuration>Transaction Service. The Transaction Service page displays the general transaction service settings. Enter the location of the transaction logs in the Transaction Log Location field.

A tx subdirectory is created and transaction logs are kept under that directory.

Setting the Keypoint Interval

Keypoint operations compress the transaction log file. The keypoint interval is the number of transactions between keypoint operations on the log. Keypoint operations can reduce the size of the transaction log files. A larger number of keypoint intervals (for example, 2048) results in larger transaction log files, but fewer keypoint operations, and potentially better performance. A smaller keypoint interval (for example, 256) results in smaller log files but slightly reduced performance due to the greater frequency of keypoint operations.

To set the keypoint interval using the Administration Console, select Configuration>Transaction Service. The Transaction Service page displays the general transaction service settings. Enter the number of transactions between keypoint operations in the Keypoint Interval field.