Sun Java System Application Server Platform Edition 8 Developer's Guide |
Chapter 12
Using the Transaction ServiceThe 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:
For more information about the Java Transaction API (JTA) and Java Transaction Service (JTS), see the Sun Java System Application Server Administration Guide and the following sites:
http://java.sun.com/products/jta/
http://java.sun.com/products/jts/
You may also want to read the chapter on transactions in the J2EE tutorial:
http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html
Transaction Resource ManagersThere are three types of transaction resource managers:
- Databases - Use of transactions prevents databases from being left in inconsistent states due to incomplete updates. Sun Java System Application Server supports a variety of JDBC XA drivers, listed in “Configurations for Specific JDBC Drivers” on page 364. For information about JDBC transaction isolation levels, see “Using JDBC Transaction Isolation Levels” on page 377.
- Java Message Service (JMS) Providers - Use of transactions ensures that messages are reliably delivered. Sun Java System 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.”
- J2EE Connector Architecture (CA) components - Use of transactions prevents legacy EIS systems from being left in inconsistent states due to incomplete updates.
For details about how transaction resource managers, the transaction service, and applications interact, see the Sun Java System Application Server Administration Guide.
Note
In the Sun Java System Application Server, the transaction manager is a privileged interface. However, applications can access UserTransaction. For more information, see “Naming Environment for J2EE Application Components” on page 388.
Transaction ScopeA 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 Sun Java System 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 (which must all be XA), or multiple participant processes, are distributed or global transactions.
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 may 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.
Sun Java System Application Server provides workarounds for some known issues with the recovery implementations of the following JDBC drivers. These workarounds are not used unless explicitly set.
- 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 should initially call this method with TMSTARTSCAN and then with TMNOFLAGS repeatedly until no Xids are returned. The XAResource.commit method also has some issues.
To enable the Sun Java System Application Server workaround, set the oracle-xa-recovery-workaround property value to true. For details about how to set this property, see Configuring the Transaction Service.
Configuring the Transaction ServiceYou can configure the transaction service in Sun Java System Application Server in the following ways:
The “Using The Administration Console” section describes each transaction service setting. The “Using The Command Line Interface” section merely lists syntax and default values.
This section covers basic configuration. For details about monitoring and other administration topics, see the Sun Java System Application Server Administration Guide.
Using the Administration Console
To configure the transaction service using the Administration Console, perform the following tasks:
- Login to the Administration Console by going to the following URL in your web browser:
http://host:port/asadmin
For example:
http://localhost:4848/asadmin
- Open the Transaction Service.
- Edit the following information if desired. All of these settings are optional.
- Recover on Restart - Check this box if you want the server to attempt transaction recovery during startup. By default, recovery is not attempted.
- Transaction Timeout - Specifies the amount of time after which the transaction is aborted. If set to 0 (the default), the transaction never times out.
This is the domain-level timeout. To set the XAResource timeout, use the xaresource-txn-timeout property, described in Step 4.
You can override the Transaction Timeout setting for an individual enterprise bean. See “Bean-Level Container-Managed Transaction Timeouts” on page 288.
- Retry Timeout - Specifies the retry timeout in the following scenarios:
- Transaction Log Location - Sets the location of the transaction log directory. The directory in which the transaction logs are kept must be writable by whatever user account the server runs as. The default location is domain_dir/logs.
- Heuristic Decision - During recovery, if the outcome of a transaction cannot be determined from the logs, this property determines the outcome. The default is rollback. The other choice is commit.
- Keypoint Interval - Specifies the number of transactions between keypoint operations in the log. Keypoint operations reduce the size of the transaction log file by compressing it. A larger value for this attribute (for example, 4096) results in a larger transaction log file, but fewer keypoint operations and 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.
- To add a property, click the Add Property button and enter the property name and value. To delete properties, check the properties you want to delete, then click the Delete Properties button. The following table lists the transaction service properties for Sun Java System Application Server.
Table 12-1 Transaction Service Properties
Property
Default
Description
oracle-xa-recovery-workaround
false
If true, the Oracle XA Resource workaround is used in transaction recovery. For details, see Transaction Scope.
disable-distributed-transaction-logging
false
If true, disables transaction logging, which may improve performance. If false, the transaction service writes transactional activity into transaction logs so that transactions can be recovered. If Recover on Restart is checked, this property is ignored.
Use only if performance is more important than transaction recovery.
xaresource-txn-timeout
specific to the XAResource used
Changes the XAResource timeout. In some cases, the XAResource default timeout causes transactions to be aborted, so it is desirable to change it.
To set the application level timeout, use the Transaction Timeout setting, described in Step 3.
- Click the Save button.
Using the Command Line Interface
To configure the transaction service using the command line interface, use the asadmin set command. The syntax is as follows, with defaults shown for optional parameters that have them:
asadmin set --user user attribute_name=value [attribute_name=value] *
For more information about the optional general asadmin parameters (--password, --passwordfile, --host, --port, --secure, --terse, --echo, and --interactive), see the Sun Java System Application Server Administration Guide.
The attribute_name is a hierarchical name that looks like this:
server.transaction-service.ts_attribute_name
The ts_attribute_name is the transaction service attribute that needs to be configured. For example:
server.transaction-service.timeout-in-seconds
To view the list of transaction service attribute names that can be configured using the asadmin set command, use the asadmin get command with a wildcard. The asadmin get command has the same syntax as the asadmin set command. For example:
asadmin get --user joeuser "server.transaction-service.*"
A list of attribute names for configuring the transaction service of the server1 application server instance is displayed. The transaction service attributes are as follows:
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/logsHere is an example of running the asadmin set command:
asadmin set --user joeuser server.transaction-service.timeout-in-seconds=0
The attribute_name for a transaction service property is a hierarchical name that looks like this:
server.transaction-service.property.ts_property_name
The instance is the application server instance name. The ts_property_name is the transaction service property that needs to be configured. Here is an example of running the asadmin set command to set a transaction service property:
asadmin set --user joeuser server.transaction-service.property.xaresource-txn-timeout=30
Transaction LoggingThe 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 the transactionLogFile attribute in the command line interface.
- 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.