| Sun Java™ System Application Server Platform Edition 8 Administration Guide |
Chapter 10
TransactionsBy enclosing one or more steps in an indivisible unit of work, a transaction ensures data integrity and consistency. This chapter contains the following sections:
About TransactionsWhat 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 will be backed out. For example, to transfer funds from a checking account to a savings account is a transaction with the following steps:
- Check to see if the checking account has enough money to cover the transfer.
- If there’s enough money in the checking account debit the amount from the checking account.
- Credit the money to the savings account.
- Record the transfer to the checking account log.
- 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 completes successfully, the transaction is in a committed state. Transactions end in either a commit or a rollback.
Transactions in J2EE Technology
Transaction processing in J2EE technology involves the following five participants: Transaction Manager, Application Server, Resource Manager(s), Resource Adapter(s) and the User Application. Each of these entities contribute to reliable transaction processing by implementing different APIs and functionalities, 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 run-time 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 Transactional User Application developed to operate in an application server environment looks up transactional data sources and, optionally, the transaction manager, using JNDI. The application may use declarative transaction attribute settings for enterprise beans or explicit programmatic transaction demarcation.
Admin Console Tasks for TransactionsConfiguring Transactions
This section explains how to configure the following transaction attributes:
Transaction Recovery
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. Sun Java™ System Application Server Platform Edition 8 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 may contact the other servers to get the outcome of the transactions. If the other servers are unreachable, it will use the Heuristic Decision field to determine the outcome.
To configure how the Application Server recovers from transactions:
- In the tree component select the Transaction Service node.
- To enable the recovery of incomplete transactions check Recover in the On Restart field.
- Set the amount of time, in seconds, the Application Server should try to connect to the unreachable server in the Retry Timeout field. The default value is 10 minutes.
- Set the policy for unreachable servers in a transaction in the Heuristic Decision field.
Unless you have a good reason to set this field to Commit, leave Heuristic Decision set to Rollback. Committing indeterminate transactions can compromise the data integrity of your application.
- Click Save.
- Restart the Application Server.
Transaction Timeouts
By default, the server will not timeout a transaction. That is, the server will wait 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 will rollback the transaction.
To set a timeout value:
Transaction Logging
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
txsubdirectory of the directory specified by the Transaction Log Location field. These logs are not meant to be human readable.To set the location of the transaction logs:
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, 1000) will result in larger transaction log files, but fewer keypoint operations, and potentially better performance. A smaller keypoint interval (for example, 20) results in smaller log files but slightly reduced performance due to the greater frequency of keypoint operations.
To set the keypoint interval:
