Transaction service settings

To modify transaction service settings, go to...

Console | Application Servers | server | Transaction Service.

 

Configuration tab

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

A blank value in the server configuration is expanded by the transaction log at startup as the directory...

$WAS_HOME/tranlog/server

When the application running on the WebSphere product accesses more than one resource, the WebSphere product stores transaction information 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, move the transaction log files to a storage device with more physical disk drives, or preferably RAID disk drives. When the log files are moved to the file systems on the raided disks, the task of writing data to the physical media is shared across the multiple disk drives. This allows more concurrent access to persist 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.

This change is applicable only to the configuration where the application uses distributed resources or XA transactions, for example, multiple databases and resources are accessed within a single transaction. Consider setting this property when the appserver shows one or more of following signs:

  • CPU utilization remains low despite an increase in transactions

  • Transactions fail with several time outs

  • Transaction rollbacks occur with unable to enlist transaction exception

  • Application server hangs in middle of a run and requires the server to be cycled

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

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 disk input and output is low, but the server is still high, consider increasing the size of the log files.

Total transaction lifetime timeout Specifies the maximum duration, in seconds, for transactions on this appserver.

Any transaction that is not requested to complete before this time-out is rolled back. If set to 0, there is no time-out limit.

Units are in seconds, with a default of 120, and a range of 0 to 2,147,483,647

Client inactivity timeout 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 rolling back in this appserver. If set to 0, there is no timeout limit.

Units are in seconds, with a default of 60, and a range of 0 to 2,147,483,647

Enable logging for heuristic reporting Select this property to enable the appserver to log "about to commit one-phase resource" events from transactions that involve 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- and two-phase commit resources. No additional records are written for transactions that do not involve a one-phase commit resource.

Options are "Cleared" and "Selected", with a default of "Cleared"

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

 

Runtime tab

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

A blank value in the server configuration is expanded by the transaction log at startup as the directory...

$WAS_HOME/tranlog/server

When the application running on the WebSphere product accesses more than one resource, the WebSphere product stores transaction information 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, move the transaction log files to a storage device with more physical disk drives, or preferably RAID disk drives. When the log files are moved to the file systems on the raided disks, the task of writing data to the physical media is shared across the multiple disk drives. This allows more concurrent access to persist 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.

This change is applicable only to the configuration where the application uses distributed resources or XA transactions, for example, multiple databases and resources are accessed within a single transaction. Consider setting this property when the appserver shows one or more of following signs:

  • CPU utilization remains low despite an increase in transactions

  • Transactions fail with several time outs

  • Transaction rollbacks occur with unable to enlist transaction exception

  • Application server hangs in middle of a run and requires the server to be cycled

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

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 disk input and output is low, but the server is still high, consider increasing the size of the log files.

Total transaction lifetime timeout Specifies the maximum duration, in seconds, for transactions on this appserver.

Any transaction that is not requested to complete before this time-out is rolled back. If set to 0, there is no time-out limit.

Units are in seconds, with a default of 120, and a range of 0 to 2,147,483,647

Client inactivity timeout 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 rolling back in this appserver. If set to 0, there is no timeout limit.

Units are in seconds, with a default of 60, and a range of 0 to 2,147,483,647