Use this page to specify settings for the transaction service. 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
.For distributed and Windows® platforms, specifies the name of a directory for this server where the transaction service stores log files for recovery.For the z/OS® platform, specifies the location of the JTA Partner Log.
In a high availability (HA) environment, both the transaction log and the compensation log directory for each server in a cluster must be unique.
If you do not specify this directory during server configuration, the transaction log uses a default that is based on your installation directory: app_server_root)/ tranlog/cell_ name/node_ name/server_ name.
When an application that runs on the application server accesses more than one resource, the application server stores transaction information in the product directory so that it can coordinate and manage the distributed transaction correctly. When there is a higher transaction load, storing persistent information in this way can slow the performance of the application server because it depends 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.
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 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 where 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.
To specify the size of transaction log files, include a file size setting. Use one of the following formats, where directory_name is the name of the transaction log directory and file_size is the disk space allocation for the transaction log files, specified in kilobytes (nK) or megabytes (nM). The minimum transaction log file size that you can specify is 64K. If you specify a value that is less than 64K, or you do not specify a value for the file size, the default value of 1M is used.
;file_size <!-- This format keeps the default directory -->
directory_name;file_size
dir://directory_name/directory_name;file_size
/directory_name/directory_name;file_size
For more information about transaction log sizes, see Managing transaction logging for optimum server availability.
Data type | String |
Default | Initial value is the app_server_root/tranlog/cell_name/node_name/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. |
On z/OS, this log is used for recovery of XA resources. When the application that runs on the WebSphere® product accesses XA resources, the WebSphere product stores information about the resource to enable XA transaction recovery. Use the following syntax:
The default is dir://app_server_root/tranlog/server name.
To specify the size of transaction log files, include a file size setting. Use one of the following formats, where directory_name is the name of the transaction log directory and file_size is the new disk space allocation for the transaction log files, specified in KB (nK) or MB (nM). The minimum transaction log file size that you can specify is 64K. If you specify a value that is less than 64K, or you do not specify a value for the file size, the default value of 1M is used.
dir://directory_name/directory_name;file_sizeK
/directory_name/directory_name;file_sizeK
;file_sizeK <!-- This keeps the default directory -->
If you migrate a WebSphere Application Server Version 5 node to Version 6, 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 Version 5 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, that a transaction that is started by this server can remain inactive before the transaction service ends it. Any transaction that does not begin completion processing before this timeout occurs is rolled back.
This timeout is used only if the application component does not set its own transaction timeout.
The upper limit of this timeout is constrained by the maximum transaction timeout. For example, if you set a value of 500 for the total transaction lifetime timeout, and a value of 300 for the maximum transaction timeout, transactions will time out after 300 seconds.
If you set this timeout to 0, the timeout does not apply and the value of the maximum transaction timeout is used instead.
Data type | Integer |
Units | Seconds |
Default | 120 |
Range |
|
Range |
|
Specifies 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 |
Specifies 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 lifetime timeout.
Timeout | Transactions affected |
---|---|
Maximum transaction timeout | All transactions running in this server that are not affected by the total transaction lifetime timeout or an application component timeout. These transactions include transactions imported from outside this server, such as those imported from a client. |
Total transaction lifetime timeout | All transactions that originated in this server that are not affected by an application component timeout, in other words, the associated application component does not set its own timeout. |
Application component timeout | Transactions that are specific to an application
component. You cannot set this transaction timeout using the administrative console. If the component is a container-managed bean, set this timeout in the deployment descriptor for the component. For example, you can use an assembly tool, such as the Rational® Application Developer. If the component is a bean-managed bean, set this timeout programmatically using the UserTransaction.setTransactionTimeout method. |
If you set a timeout to 0, that timeout does not apply, and is effectively disabled. If you set all timeouts to 0, transactions never time out.
Timeout | Value |
---|---|
Maximum transaction timeout | 360 |
Total transaction lifetime timeout | 240 |
Application component timeout | 60 |
To determine the occurrence of a timeout as quickly as possible and to prevent further resource locking, WebSphere Application Server prevents further transactional work on the transactional path where the timeout condition has taken place. This applies equally to attempting to perform work under the current transaction context and to attempting to perform work under a different transactional context.
Data type | Integer |
Units | Seconds |
Default | 300 |
Range | 0 to 2 147 483 647 |
Range | 0 to 2 147 040 |
Specifies 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.
During recovery of a subordinate server in a distributed transaction, when the number of heuristic retries is exceeded, the heuristic completion direction property specifies how the transaction is completed.
Data type | Integer |
Default | 0 |
Range | 0 to 2 147 483 647 A value of 0 (the default) means try repeatedly forever. |
Specifies the number of seconds that the application server waits before trying again to send 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
|
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 |
|
Specifies 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.
This property applies only to transactions that are in the situations just described.
Data type | Drop-down list |
Default | ROLLBACK |
Range |
|
For distributed and Windows® platforms, specifies the name of a directory for this server where the transaction service stores log files for recovery.For the z/OS® platform, specifies the location of the JTA Partner Log.
In a high availability (HA) environment, both the transaction log and the compensation log directory for each server in a cluster must be unique.
If you do not specify this directory during server configuration, the transaction log uses a default that is based on your installation directory: app_server_root)/ tranlog/cell_ name/node_ name/server_ name.
When an application that runs on the application server accesses more than one resource, the application server stores transaction information in the product directory so that it can coordinate and manage the distributed transaction correctly. When there is a higher transaction load, storing persistent information in this way can slow the performance of the application server because it depends 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.
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 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 where 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.
To specify the size of transaction log files, include a file size setting. Use one of the following formats, where directory_name is the name of the transaction log directory and file_size is the disk space allocation for the transaction log files, specified in kilobytes (nK) or megabytes (nM). The minimum transaction log file size that you can specify is 64K. If you specify a value that is less than 64K, or you do not specify a value for the file size, the default value of 1M is used.
;file_size <!-- This format keeps the default directory -->
directory_name;file_size
dir://directory_name/directory_name;file_size
/directory_name/directory_name;file_size
For more information about transaction log sizes, see Managing transaction logging for optimum server availability.
Data type | String |
Default | Initial value is the app_server_root/tranlog/cell_name/node_name/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. |
On z/OS, this log is used for recovery of XA resources. When the application that runs on the WebSphere® product accesses XA resources, the WebSphere product stores information about the resource to enable XA transaction recovery. Use the following syntax:
The default is dir://app_server_root/tranlog/server name.
To specify the size of transaction log files, include a file size setting. Use one of the following formats, where directory_name is the name of the transaction log directory and file_size is the new disk space allocation for the transaction log files, specified in KB (nK) or MB (nM). The minimum transaction log file size that you can specify is 64K. If you specify a value that is less than 64K, or you do not specify a value for the file size, the default value of 1M is used.
dir://directory_name/directory_name;file_sizeK
/directory_name/directory_name;file_sizeK
;file_sizeK <!-- This keeps the default directory -->
If you migrate a WebSphere Application Server Version 5 node to Version 6, 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 Version 5 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, that a transaction that is started by this server can remain inactive before the transaction service ends it. Any transaction that does not begin completion processing before this timeout occurs is rolled back.
This timeout is used only if the application component does not set its own transaction timeout.
The upper limit of this timeout is constrained by the maximum transaction timeout. For example, if you set a value of 500 for the total transaction lifetime timeout, and a value of 300 for the maximum transaction timeout, transactions will time out after 300 seconds.
If you set this timeout to 0, the timeout does not apply and the value of the maximum transaction timeout is used instead.
Data type | Integer |
Units | Seconds |
Default | 120 |
Range |
|
Range |
|
Specifies 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 |
Specifies 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 lifetime timeout.
Timeout | Transactions affected |
---|---|
Maximum transaction timeout | All transactions running in this server that are not affected by the total transaction lifetime timeout or an application component timeout. These transactions include transactions imported from outside this server, such as those imported from a client. |
Total transaction lifetime timeout | All transactions that originated in this server that are not affected by an application component timeout, in other words, the associated application component does not set its own timeout. |
Application component timeout | Transactions that are specific to an application
component. You cannot set this transaction timeout using the administrative console. If the component is a container-managed bean, set this timeout in the deployment descriptor for the component. For example, you can use an assembly tool, such as the Rational® Application Developer. If the component is a bean-managed bean, set this timeout programmatically using the UserTransaction.setTransactionTimeout method. |
If you set a timeout to 0, that timeout does not apply, and is effectively disabled. If you set all timeouts to 0, transactions never time out.
Timeout | Value |
---|---|
Maximum transaction timeout | 360 |
Total transaction lifetime timeout | 240 |
Application component timeout | 60 |
To determine the occurrence of a timeout as quickly as possible and to prevent further resource locking, WebSphere Application Server prevents further transactional work on the transactional path where the timeout condition has taken place. This applies equally to attempting to perform work under the current transaction context and to attempting to perform work under a different transactional context.
Data type | Integer |
Units | Seconds |
Default | 300 |
Range | 0 to 2 147 483 647 |
Range | 0 to 2 147 040 |
Specifies 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 |
Specifies 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 |
Specifies 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 |
Specifies 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 |