Use this task to configure the transaction properties required for peer recovery of failed application servers in a cluster.
Transaction peer recovery requires a common configuration of the resource providers between the participating server members in order to be able to perform peer recovery between servers. This means that peer recovery processing can only take place between members of the same server cluster. Although a cluster can contain servers that are at different versions of WebSphere Application Server, enable and configure high availability only if all servers in the cluster are at Version 6 or later.
Configuring the transaction properties required for peer recovery is part of the overall task for configuring a cluster to use high availability support.
To configure the transaction properties required for peer recovery, complete the following steps:
Each server in the cluster must be able to access the log directories of other servers in the same cluster. For this reason, do not leave this setting unset. If you do not set a directory the application server will assume a default location within the appropriate profile directory, which may not be accessible to other servers in the cluster.
The storage mechanism used to host recovery log files (for example, you can use IBM NAS and shared SCSI drives, but not simple network share) and access to that mechanism (for example, through a LAN), must support the file-based force operation that is used by the recovery log service to force data to disk.
For more information about configuring transaction log directories, see Configuring transaction properties for an application server.
Note: If you have migrated from a previous version of WebSphere Application Server, be aware that previous versions stored the recovery log configuration in the server.xml server-level configuration file. If you run existing scripting that configures the original recovery log settings, or migrate Version 5 application servers to Version 6, the original transaction log directory configuration in the server.xml file is updated. The administrative console detects this condition and prompts you to save the configuration when you view the transaction service panel. This save operation saves the changed configuration to the serverindex.xml file, and resets the older fields to null. Change your existing scripting
to target the serverindex.xml file at the earliest opportunity. New
scripting should also target the serverindex.xml file.
Related concepts
Transactional high availability
Related tasks
Using the transaction service