(iSeries)

(Dist) Manage transaction logging for optimum server availability

We can manage transaction logging to optimize the availability of the application servers.

The transaction service writes information to the transaction log for every global transaction that involves two or more resources, or that is distributed across multiple servers. The transaction log is stored on disk and is used by the transaction service for recovery after a system or server crash. The transaction log for each application server consists of multiple subdirectories and files held in a single directory. To change the directory an application server uses to store the transaction log, change the transaction log directory in the transaction service settings.

When a global transaction is completed, the information in the transaction log is no longer required, and the information is marked for deletion. The redundant information is garbage collected and intervals, and the space is reused by new transactions. The log files are created with a fixed size at server startup, so no further disk space allocation is required during the lifetime of the server.

If all the log space is in use when a transaction needs to save information, the transaction is rolled back and the message CWWTR0083W: The transaction log is full. Transaction rolled back. is reported to the system error log. No more transactions can commit until more log space is made available when existing active transactions complete.

The default disk space allocation for the transaction logs is 1M. For global transactions that involve only XA resources and that are either local to an application server or are distributed between enterprise beans running in remote application servers, the default disk space allocation is suitable for peak workloads of up to 4000 concurrent two-phase commit transactions. For global transactions that involve Web Services Atomic Transaction (WS-AT) transactions or interoperable OTS transactions, the default disk space allocation is suitable for peak workloads of up to 250 concurrent two-phase commit transactions. For higher workloads, consider using a larger transaction log. To change the disk space allocation for the transaction log files, change the transaction log directory in the transaction service settings.

We can monitor the number of concurrent global transactions using the performance monitoring counters for transactions. The "Global transaction commit time" counter is a measure of how long a transaction takes to complete and, therefore, how long the log is in use by a transaction. If this value is high, then transactions are taking a long time to complete, which can be due to resource manager or network failures. If we ensure that this value is low, the log is more efficiently used and unlikely to become full.

Use the following tasks to manage transaction logging to optimize the availability of the application servers:

Tasks

• Configure transaction aspects of servers for optimum availability. Configure the transaction properties for an application server to help transactions to complete or recover more quickly.
• Move a transaction log from one server to another Use this task if we have to move a transaction log between servers.
• Restarting an application server on a different host Use this task to restart the application server if you move a transaction log between hosts.
• Configure transaction properties for an application server Change the directory or the disk space allocation for the transaction log files.

Subtopics

• Configure transaction aspects of servers for optimum availability
  We can configure transaction-related aspects of application servers to optimize the availability of those servers. This helps your transactions to complete or recover more quickly. After changing transaction-related properties of an application server, we must restart the server.
• Move a transaction log from one server to another
  We can move the transaction logs for an application server to another server.
• Restarting an application server on a different host
  As part of restarting an application server on a different host, you move all the transaction logs to the new host.
• Storing and restoring transaction and compensation logs for high availability
  We can, optionally, choose to store the WebSphere Application Server transaction and compensation logs in a relational database rather than as operating system files. This feature provides high availability (HA) support without having to use a shared file system. We can also restore your transaction and compensation logs from the relational database to the operating system files.

Configure transaction properties for an application server

Transaction service settings