![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Storing and restoring transaction and compensation logs for high availability
You can, optionally, choose to store your 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. You can also restore your transaction and compensation logs from the relational database to the operating system files.
About this task
The WebSphere Application Server transaction service writes information to a transaction log for every global transaction that involves two or more resources, or that is distributed across multiple servers. These transactions are started or stopped either by applications or by the container in which they are deployed. The transaction service maintains transaction logs to ensure the integrity of transactions. Information is written to the transaction logs in the prepare phase of a distributed transaction. If a WebSphere Application Server with active transactions restarts after a failure, the transaction service is able to use the logs to replay any in-doubt transactions. This level of integrity allows the overall system to be brought back to a consistent state.
In previous releases of WebSphere Application Server, the transaction logs were stored as operating system files. In WebSphere Application Server Version 8.5.5 and later, this setup remains the default configuration. You can also choose to store the transaction logs in a relational database. This configuration option is primarily used for a high availability (HA) environment. Also, in previous releases of WebSphere Application Server, HA transaction support required the use of a shared file system to host the transaction logs, such as an NFSv4-mounted network-attached storage (NAS) or a storage area network (SAN). This new feature enables you, particularly if you have an investment in HA database technology, to use your HA database as a shared repository for the transaction logs as an alternative to using a shared file system.
In the current implementation, if unexpected JDBC exceptions are encountered by the core recovery log function, transaction logging is disabled and the server must be shut down so that in-flight transactions can be recovered. No attempt is made to reconnect until the server is restarted, and no attempt is made by the current implementation to determine whether the condition is transient.
In WebSphere Application Server Version 8.5.5 and later, you can use a similar facility, also aimed at customers that are working in a HA environment, to store the compensation recovery logs in a relational database. The WebSphere Application Server compensation service enables applications on disparate systems to coordinate activities that are more loosely coupled than atomic transactions. It stores information that is necessary to complete compensation after a system failure in its own dedicated recovery logs.

(2 * the number of potential servers being peer recovered) + 2
This
max pool size allows for sufficient connections to the database to close all the related transaction
logs. Not having a max pool size set to this value can lead to the error message, J2CA0045E, because
there are not sufficient connections available.gotchaFor the procedure to restore transaction and compensation logs from the relational
database to operating system files, see step
5.
Procedure
- AppClusterMember1
- AppClusterMember2
- AppClusterMember3
- AppClusterMember4
- App1 for AppClusterMember1
- App2 for AppClusterMember2
- App3 for AppClusterMember3
- App4 for AppClusterMember4
Complete the following steps:
Example
Cluster Name | Server Name | Transaction Log Table | Compensation Log Table |
---|---|---|---|
AppCluster | AppClusterMember1 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App1 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App1 |
AppClusterMember2 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App2 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App2 | |
AppClusterMember3 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App3 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App3 | |
AppClusterMember4 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App4 | custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App4 |
- AppClusterMember1
- AppClusterMember2
- AppClusterMember3
- AppClusterMember4
- WAS_TRAN_LOGApp1
- WAS_TRAN_LOGApp2
- WAS_TRAN_LOGApp3
- WAS_TRAN_LOGApp4
- WAS_PARTNER_LOGApp1
- WAS_PARTNER_LOGApp2
- WAS_PARTNER_LOGApp3
- WAS_PARTNER_LOGApp4
- WAS_COMP_LOGApp1
- WAS_COMP_LOGApp2
- WAS_COMP_LOGApp3
- WAS_COMP_LOGApp4