|
|
The WAS Transaction Manager writes to its transaction recovery logs when it handles global transactions that involve two or more resources. Transaction recovery logs are stored on disk and are used for recovering in-flight transactions from system crashes or process failures. To enable WebSphere appserver transaction peer recovery, it is necessary to place the recovery logs on a highly available file system, such as IBM SAN FS or NAS, for all the appservers within the same cluster to access. All appservers must be able to read from and write to the logs.
For a peer server to recover in-flight transactions, any database locks associated with the failed transactions should be released prior to the recovery. We need to use the lease-based exclusive locking protocol, such as Common Internet File System (CIFS) or Network File System (NFS) Version4, to access remote recovery logs from WebSphere appserver nodes. Without the lease-based locking support, if one of the nodes crashes, locks held by all the processes on that node will not automatically be released. As a result, the transactions cannot be completed, and database access can be impaired due to the unreleased locks.
As depicted in Figure 6-13, as two appservers perform two-phase commit (2PC) transactions, they place table or row locks in the database, depending on the configuration of lock granularity.
Figure 6-13 Two phase commit transactions and database locking
In the event of a server failure, the transaction service of the failed appserver is out of service. Also, the in-flight transactions that have not be committed might leave locks in the database, which blocks the peer server from gaining access to the locked records.
Figure 6-14 Server failure during an in-flight transaction
There are only two ways to complete the transactions and release the locks. One is to restart the failed server and the other is to start an appserver process on another box that has access to the transaction logs.
Figure 6-15 Recovery of failed transactions
Using the new HAManager support, a highly available file system and a lease-based locking protocol, a recovery process will be started in a peer member of the cluster. The recovery locks are released and in-flight transactions are committed.
We describe this configuration in detail in the next sections.
