|
In order to explain how to configure the Transaction Manager peer recovery with the No Operation (NoOP) policy, we use the Trade 6 application in the topology shown in Figure 9-20. In this sample topology, the WebSphere hardware environment consists of two nodes and a shared file system. The cell contains one cluster with two cluster members, one on each node. Each cluster member has its own transaction log.
![]()
Figure 9-20 Sample topology for TM with NoOP policy
The scenario is as follows: one cluster member fails and the other cluster member takes over the transaction log to perform a peer recovery of in-doubt transactions. The NoOP policy indicates that external clustering software controls the actions of selecting which cluster member performs the transaction recovery and when this cluster member performs the recovery.
The example that we tested and that we describe here is an Active/Active solution for hot failover/log recovery. This means that both cluster members are actively running and processing transactions. When one cluster member fails, then the external clustering software directs the other cluster member to perform the recovery of the failing cluster member transaction log.
Our cluster name is TradeCluster, the cluster members are called TradeServer1 and TradeServer2.
The procedures needed to configure WebSphere and the external clustering software are described in the sections that follow.