Use this page to specify settings for the transaction service settings. The transaction service is a server runtime component that can coordinate updates to multiple resource managers to ensure atomic updates of data. Transactions are started and ended by applications or the container in which the applications are deployed.
To view this administrative console page, click...
Servers | Application Servers | server_name | Container Services | Transaction Service
Specifies the name of a directory for this server where the transaction service stores log files for recovery.
If you do not specify this directory during server configuration, the transaction log uses a default that is based on your installation directory:
install_root/tranlog/cell_name/node_ name/server_name
When an application running on WAS accesses more than one resource, Application Server stores transaction information within the product directory to properly coordinate and manage the distributed transaction. In a higher transaction load, this persistence slows down performance of the application server due to its dependency on the operating system and the underlying storage systems. To achieve better performance, designate a new directory for the log files on a separate, physically larger storage system.
Set this property to change the log file directory for an application server only if the applications use distributed resources or XA transactions; for example, multiple databases and resources are accessed within a single transaction. If your application server demonstrates one or more of the following symptoms, change log file directories.
File system recommendations:
In RAID configurations, the task of writing data to the physical media is shared across the multiple drives. This technique yields more concurrent access to storage for persisting transaction information, and faster access to that data from the logs. Depending upon the design of the application and storage subsystem, performance gains can range from 10% to 100%, or even more in some cases.
When you designate a transaction log directory, ensure that the file system uses only synchronous write-through and write serialization operations. Some operating systems, such as AIX JFS2, support an optional concurrent I/O (CIO) mode whereby the file system does not enforce serialization of write operations. On these systems, do not use CIO mode for Application Server transaction recovery log files.
| Data type | String |
| Default | Initial value is...
install_root /tranlog/cell_name/node/server_name ...and a default size of 1MB. |
| Recommended | Create a file system with at least 3-4 disk drives raided together in a RAID-0 configuration. Then, create the transaction log on this file system with the default size. When the server is running under load, check the disk input and output. If disk input and output time is more then 5%, consider adding more physical disks to lower the value. |
If you migrate a WAS V5 node to V6, the stored location of this configuration property is moved from the server level to the node (server index) level. If you have specified a non-default log directory for a V5 application server, you are prompted to save the transaction service settings again, to confirm that you want the log directory saved to the node level.
The default maximum time, in seconds, allowed for transactions started on this server to complete. Any such transactions that do not complete before this timeout occurs are rolled back.
If you set this value to 0, only the maximum transaction timeout configuration value applies.
| Data type | Integer |
| Units | Seconds |
| Default | 120 |
| Range | 0 to 2 147 483 647 |
The maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server.
If you set this value to 0, there is no timeout limit.
| Data type | Integer |
| Units | Seconds |
| Default | 60 |
| Range | 0 to 2 147 483 647 |
The maximum time to complete, in seconds, for transactions that run in this server. This value should be greater than or equal to the total transaction timeout.
This limit constrains transaction timeout set programmatically by BMT beans and values imported with contexts received from foreign servers.
This value limits the upper bound of all other transaction related timeouts. For example, if a component attempts to set a transaction timeout of 360 seconds, and the Maximum Transaction Timeout setting is 300 seconds, the Maximum Transaction Timeout setting of 300 seconds is used.
If set to 0, there is no limit and therefore the timeout specified by the Total transaction lifetime timeout property or component timeout is used.
| Data type | Integer |
| Units | Seconds |
| Default | 300 |
| Range | 0 to 2 147 040 |
The number of times that the application server retries a completion signal, such as commit or rollback, after a transient exception from a resource manager or remote partner.
If the application server abandons the retries, then the resource manager or remote partner is responsible for ensuring that the resource or partner's branch of the transaction is completed appropriately. The application server raises (on behalf of the resource or partner) an exception that indicates a heuristic hazard. If a commit was requested, the transaction originator receives an exception on the commit operation; if the transaction is container-initiated, then the container returns a remote exception or EJB exception to the EJB client.
| Data type | Integer |
| Default | 0 |
| Range | 0 to 2 147 483 647
A value of 0 (the default) means retry forever. |
The number of seconds that the application server waits before retrying a completion signal, such as commit or rollback, after a transient exception from a resource manager or remote partner.
| Data type | Integer |
| Default | 0 |
| Range | 0 to 2 147 483 647
A value of 0 means that the application server determines the retry wait; the server doubles the retry wait after every 10 failed retries. |
Specifies whether the application server will log about-to-commit-one-phase-resource events from transactions that involve both a one-phase commit resource, and two-phase commit resources.
This property enables logging for heuristic reporting. If applications are configured to allow one-phase commit resources to participate in two-phase commit transactions, reporting of heuristic outcomes that occur at application server failure requires extra information to be written to the transaction log. If enabled, one additional log write is performed for any transaction that involves both one-phase and two-phase commit resources. No additional records are written for transactions that do not involve a one-phase commit resource.
| Data type | Check box |
| Default | Cleared |
| Range |
|
The direction used to complete a transaction that has a heuristic outcome; either the application server commits or rolls back the transaction, or depends on manual completion by the administrator.
| Data type | Drop-down list |
| Default | ROLLBACK |
| Range |
|
Runtime tab
Specifies the name of a directory for this server where the transaction service stores log files for recovery.
If you do not specify this directory during server configuration, the transaction log uses a default that is based on your installation directory:
install_root/tranlog/cell_name/node_name/server_ name
When an application running on WAS accesses more than one resource, Application Server stores transaction information within the product directory to properly coordinate and manage the distributed transaction. In a higher transaction load, this persistence slows down performance of the application server due to its dependency on the operating system and the underlying storage systems. To achieve better performance, designate a new directory for the log files on a separate, physically larger storage system.
Set this property to change the log file directory for an application server only if the applications use distributed resources or XA transactions; for example, multiple databases and resources are accessed within a single transaction. If your application server demonstrates one or more of the following symptoms, change log file directories.
File system recommendations:
In RAID configurations, the task of writing data to the physical media is shared across the multiple drives. This technique yields more concurrent access to storage for persisting transaction information, and faster access to that data from the logs. Depending upon the design of the application and storage subsystem, performance gains can range from 10% to 100%, or even more in some cases.
When you designate a transaction log directory, ensure that the file system uses only synchronous write-through and write serialization operations. Some operating systems, such as AIX JFS2, support an optional concurrent I/O (CIO) mode whereby the file system does not enforce serialization of write operations. On these systems, do not use CIO mode for Application Server transaction recovery log files.
| Data type | String |
| Default | Initial value is the install_root /tranlog/cell_name/node/server_name directory and a default size of 1MB. |
| Recommended | Create a file system with at least 3-4 disk drives raided together in a RAID-0 configuration. Then, create the transaction log on this file system with the default size. When the server is running under load, check the disk input and output. If disk input and output time is more then 5%, consider adding more physical disks to lower the value. |
If you migrate a WAS V5 node to V6, the stored location of this configuration property is moved from the server level to the node (server index) level. If you have specified a non-default log directory for a V5 application server, you are prompted to save the transaction service settings again, to confirm that you want the log directory saved to the node level.
The default maximum time, in seconds, allowed for transactions started on this server to complete. Any such transactions that do not complete before this timeout occurs are rolled back.
If you set this value to 0, only the maximum transaction timeout configuration value applies.
| Data type | Integer |
| Units | Seconds |
| Default | 120 |
| Range | 0 to 2 147 483 647 |
The maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server.
If you set this value to 0, there is no timeout limit.
| Data type | Integer |
| Units | Seconds |
| Default | 60 |
| Range | 0 to 2 147 483 647 |
The maximum time to complete, in seconds, for transactions that run in this server. This value should be greater than or equal to the total transaction timeout.
This limit constrains transaction timeout set programmatically by BMT beans and values imported with contexts received from foreign servers.
This value limits the upper bound of all other transaction related timeouts. For example, if a component attempts to set a transaction timeout of 360 seconds, and the Maximum Transaction Timeout setting is 300 seconds, the Maximum Transaction Timeout setting of 300 seconds is used.
If set to 0, there is no limit and therefore the timeout specified by the Total transaction lifetime timeout property or component timeout is used.
| Data type | Integer |
| Units | Seconds |
| Default | 300 |
| Range | 0 to 2 147 040 |
The number of transactions that are awaiting manual completion by an administrator.
If there are transactions awaiting manual completion, you can click the Review link to display a list of those transactions on the Transactions needing manual completion panel.
| Data type | Integer |
| Default | 0 |
The number of transactions with some resources being retried.
If there are transactions with resources being retried, you can click the Review link to display a list of those transactions on the Transactions retrying resources panel.
| Data type | Integer |
| Default | 0 |
The number of transactions that have completed heuristically.
If there are transactions that have completed heuristically, you can click the Review link to display a list of those transactions on the Transactions with heuristic outcome panel.
| Data type | Integer |
| Default | 0 |
The number of transactions that are imported and prepared but not yet committed.
If there are transactions that have been imported and prepared but not yet committed, you can click the Review link to display a list of those transactions on the Transactions imported and prepared panel.
| Data type | Integer |
| Default | 0 |
Transactions needing manual completion
Transactions retrying resources
Transactions with heuristic outcome
Transactions imported and prepared
Related tasks
Disable file locking
Configure transaction properties for an application
server