Configuring Transactions

The Java Transaction API (JTA) services protect data integrity and are critical to most enterprise applications. Almost all JTA settings are configured through data sources and EJB settings, as described in Chapters 5 and 11, respectively. However, server.xml does contain the following two very important settings.

Transaction Timeout

The transaction timeout controls how long a transaction can run before it's rolled back. When set too high, one long-running search or deadlock can bring the server to its knees as database connections are queued up, waiting for tables to be freed. When set too low, some legitimate queries or updates may run out of time and fail.

The following example sets the transaction timeout to 60 seconds (the default):

 <transaction-config timeout="60000"/> 

This is much too high for most web applications, since few users are willing to wait 60 seconds for a response. Ideally, you should lower this value to the length of your longest running query or update. For many applications, 10 seconds is sufficient. If you find that you need a timeout greater than 30 seconds, you many want to try redesigning the code.

Transaction Recovery

Occasionally, the server may encounter a fatal error in the middle of a global transaction, which as a result is never committed or rolled back. These transactions are written to a file, thereby allowing OC4J to attempt to complete them the next time it starts. This behavior can be configured inside server.xml , using the recovery-procedure attribute of the root <application-server> element.

For example, the following (default) configuration tells the server to always attempt to recover transactions:

 <application-server recovery-procedure="automatic" ...> 

The allowed values are as follows :

• automatic . OC4J will automatically attempt to recover interrupted transactions.

• prompt . OC4J will prompt the user at the console before recovering transactions.

• ignore . OC4J will never recover interrupted transactions (faster).