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.
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,
so that 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 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.0 fix pack 7 and later, this remains the default
configuration but you can, optionally, choose to store the transaction
logs in a relational database. This configuration option is aimed
at customers working in a high availability (HA) environment. 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 allows
customers, particularly those with an investment in HA database technology,
to use their HA database as a shared repository for the transaction
logs, as an alternative to using a shared file system.
Note: The current implementation for storing the transaction
and compensation logs in a relational database does not ensure support
for any database-specific features that the database clients (in this
case WebSphere Application Server Transaction Service) might use to
enhance HA capabilities. For example, client-specific features such
as DB2 HADR or Oracle RAC DataGuard that allow reconnection to another
database instance in the event of a failure might not be supported.
If JDBC exceptions are encountered when connecting to the database,
then the server is shut down and the peer recovery process follows.
No attempt is made to reconnect until the server is restarted.
In WebSphere Application Server
Version 8.0 fix pack 7 and later, you can use a similar facility,
also aimed at customers working in a HA environment, to store the
compensation recovery logs in a relational database. The WebSphere Application Server compensation
service allows applications on disparate systems to coordinate activities
that are more loosely coupled than atomic transactions. It stores
information, in its own dedicated recovery logs, that is necessary
to perform compensation after a system failure.
You must configure the transaction log location and
the compensation log location for each server in the cluster before
enabling high availability, by setting the TransactionLogDirectory
and CompensationLogDirectory attributes for each server. Each server
in a cluster must reference unique transaction log and compensation
log directories, by specifying a distinct tablesuffix property, so
that multiple servers do not contend for relational database management
system (RDBMS) resources.
Important: ![[Updated in February 2014]](../images/delta.gif)
Each
server in the cluster must be able to reference the datasource that
a given application server references for its logs. That is, the datasource
must be scoped to the cluster (or cell). This scoping allows peer
recovery.
![[Updated in February 2014]](../images/deltaend.gif)