Transaction service settings

 

+

Search Tips   |   Advanced Search

 

To specify settings for the transaction service, from the console...

Servers | Application Servers | server | Container Services | 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.

 

Configuration tab

 

Transaction log directory

Name of a directory for this server where the transaction service stores log files for recovery.

Set this property to change the log file directory for an appserver in one of the following scenarios:

• If the applications use distributed resources or XA transactions; for example, multiple databases and resources are accessed within a single transaction.

• If you configured your system for high availability of transactions. In this scenario, the transaction log directory must be accessible by all servers in the cluster, and must also be unique within the cluster.

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/node/server

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 appserver 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.

If your appserver demonstrates one or more of the following symptoms, change log file directories.

• CPU utilization remains low despite an increase in transactions
• Transactions fail with several timeouts
• Transaction rollbacks occur with unable to enlist transaction exception
• The appserver hangs in the middle of a run and requires the server to be restarted
• The disk on which an appserver is running shows higher utilization

File system recommendations:

• Store log files on a redundant array of independent disks (RAID)

  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.

• Do not store log files with the operation system I/O mode set to concurrent I/O (CIO)

  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... app_server_root/tranlog/cell/node/server ...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 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 V5 appserver, you are prompted to save the transaction service settings again, to confirm that you want the log directory saved to the node level.

Total transaction lifetime timeout

The default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. 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 timeout 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	0 to 2 147 483 647

Asynchronous response timeout

Specify the amount of time, in seconds, that the server waits for an inbound Web Services Atomic Transaction (WS-AT) protocol response before resending the previous WS-AT protocol message.

Data type	Integer
Units	Seconds
Default	30
Range	0 to 2 147 483 647

Client inactivity timeout

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 appserver.

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

Maximum transaction timeout

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 timeout constrains the upper limit of all other transaction timeouts. The following table shows how the different timeouts apply to transactions running in the server.

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 set this timeout either in the deployment descriptor for the component, if the component is a container-managed bean, or programmatically using the UserTransaction.setTransactionTimeout method, if the component is a bean-managed bean.

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.

For example, consider the following timeout values:

Timeout	Value
Maximum transaction timeout	360
Total transaction lifetime timeout	240
Application component timeout	60

In this example, transactions that are specific to the application component timeout after 60 seconds, other local transactions timeout after 240 seconds, and any transactions that are imported from outside this server timeout after 360 seconds. If you then change the application component timeout to 500, application component transactions timeout after 360 seconds, the value of the maximum transaction timeout. If you set the maximum transaction timeout to 0, application component transactions timeout after 500 seconds. If you remove the application component timeout, application component transactions timeout after 240 seconds.

Data type	Integer
Units	Seconds
Default	300
Range	0 to 2 147 483 647

Heuristic retry limit

Number of times that the appserver retries a completion signal, such as commit or rollback. Retries occur after a transient exception from a resource manager or remote partner, or if the configured asynchronous response timeout expires before all Web Services Atomic Transaction (WS-AT) partners have responded.

If the appserver 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 appserver 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.

Heuristic retry wait

Number of seconds that the appserver 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 appserver determines the retry wait; the server doubles the retry wait after every 10 failed retries.

Enable logging for heuristic reporting

Specify whether the appserver logs 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 appserver 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	Cleared The appserver does not log "about to commit one-phase resource" events from transactions that involve a one-phase commit resource and two-phase commit resources. Selected The appserver does log "about to commit one-phase resource" events from transactions that involve a one-phase commit resource and two-phase commit resources.

Heuristic completion direction

Specify the direction that is used to complete a transaction that has a heuristic outcome; either the appserver commits or rolls back the transaction, or depends on manual completion by the administrator.

Data type	Drop-down list
Default	ROLLBACK
Range	COMMIT The Application server heuristically commits the transaction. ROLLBACK The Application server heuristically rolls back the transaction. MANUAL The appserver depends on an administrator to manually complete or roll back transactions with heuristic outcomes.

Enable file locking

Specify whether the use of file locks is enabled when opening the transaction service recovery log.

If you enable this setting, a file lock will be obtained before accessing the transaction service recovery log files. File locking is used to ensure that, in a highly available WAS deployment, only one appserver can access a particular transaction service recovery log at any one time. This setting has no effect in a standard deployment where you have not configured high availability support.

This setting requires a compatible network file system, such as network file system version 4, to operate correctly.

Data type	Check box
Default	Selected

Enable protocol security

Specify whether the secure exchange of transaction service protocol messages is enabled.

This setting has no effect unless you enable WAS security on the server.

Data type	Check box
Default	Selected

HTTP proxy prefix

Prefix used by WS-AtomicTransaction and WS-BusinessActivity requests that are sent through an intermediary node using the HTTP protocol.

Set this field if you are using an intermediary node, such as an HTTP server or Proxy Server for WebSphere, to send requests that comply with the Web Services Atomic Transaction or Web Services Business Activity protocols. The format for the prefix is as follows:

http://host_name:port

where

• host_name is the host name used by clients to contact the Web service

• port is the port for which the service is configured to accept client requests

If the intermediary node is not a Proxy Server, the prefix must be unique for each server. If you are using a Proxy Server, prefixes can be the same for each server in a cluster, because the Proxy Server determines dynamically which server to forward the request to.

The HTTPS prefix will be used if WAS security is enabled and protocol security is enabled for the transaction service, otherwise the HTTP prefix will be used.

Data type	String
Default	None

HTTPS proxy prefix

Prefix used by WS-AtomicTransaction and WS-BusinessActivity requests that are sent through an intermediary node using the HTTPS protocol.

Set this field if you are using an intermediary node, such as an HTTP server or Proxy Server for WebSphere, to send requests that comply with the Web Services Atomic Transaction or Web Services Business Activity protocols. The format for the prefix is as follows:

https://host_name:port

where

• host_name is the host name used by clients to contact the Web service

• port is the port for which the service is configured to accept client requests

If the intermediary node is not a Proxy Server, the prefix must be unique for each server. If you are using a Proxy Server, prefixes can be the same for each server in a cluster, because the Proxy Server determines dynamically which server to forward the request to.

The HTTPS prefix will be used if WAS security is enabled and protocol security is enabled for the transaction service, otherwise the HTTP prefix will be used.

Data type	String
Default	None

 

Runtime tab

 

Transaction log directory

Directory where servers stores transaction service log files for recovery.

Set this property to change the log file directory for an appserver in one of the following scenarios:

• If the applications use distributed resources or XA transactions; for example, multiple databases and resources are accessed within a single transaction.

• If you configured your system for high availability of transactions. In this scenario, the transaction log directory must be accessible by all servers in the cluster, and must also be unique within the cluster.

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 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 appserver 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.

If your appserver demonstrates one or more of the following symptoms, change log file directories.

• CPU utilization remains low despite an increase in transactions

• Transactions fail with several timeouts

• Transaction rollbacks occur with unable to enlist transaction exception

• The appserver hangs in the middle of a run and requires the server to be restarted

• The disk on which an appserver is running shows higher utilization

File system recommendations:

• Store log files on a redundant array of independent disks (RAID)

  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.

• Do not store log files with the operation system I/O mode set to concurrent I/O (CIO)

  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 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.

If you migrate a WAS V5 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 V5 appserver, you are prompted to save the transaction service settings again, to confirm that you want the log directory saved to the node level.

Total transaction lifetime timeout

The default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. 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 timeout 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	0 to 2 147 483 647

Asynchronous response timeout

Specify the amount of time, in seconds, that the server waits for an inbound Web Services Atomic Transaction (WS-AT) protocol response before resending the previous WS-AT protocol message.

Data type	Integer
Units	Seconds
Default	30
Range	0 to 2 147 483 647

Client inactivity timeout

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 appserver.

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

Maximum transaction timeout

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 timeout constrains the upper limit of all other transaction timeouts. The following table shows how the different timeouts apply to transactions running in the server.

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 set this timeout either in the deployment descriptor for the component, if the component is a container-managed bean, or programmatically using the UserTransaction.setTransactionTimeout method, if the component is a bean-managed bean.

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.

For example, consider the following timeout values:

Timeout	Value
Maximum transaction timeout	360
Total transaction lifetime timeout	240
Application component timeout	60

In this example, transactions that are specific to the application component timeout after 60 seconds, other local transactions timeout after 240 seconds, and any transactions that are imported from outside this server timeout after 360 seconds. If you then change the application component timeout to 500, application component transactions timeout after 360 seconds, the value of the maximum transaction timeout. If you set the maximum transaction timeout to 0, application component transactions timeout after 500 seconds.

If you remove the application component timeout, application component transactions timeout after 240 seconds.

Data type	Integer
Units	Seconds
Default	300
Range	0 to 2 147 483 647

Manual transactions

Number of transactions that await 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

Retry transactions

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

Heuristic transactions

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

Imported prepared transactions

Number of transactions that are imported and prepared but not yet committed.

If there are transactions 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

---

Sub-topics

Transactions needing manual completion
Transactions retrying resources
Transactions with heuristic outcome
Transactions imported and prepared
Transaction resources

 

Related concepts

Web Services transactions, firewalls and intermediary nodes

 

Related tasks

Disabling file locking
Configure transaction properties for an appserver