Chapter 19 Fault Tolerance : Unshared State Failover Process

Unshared State Failover Process
This section presents details of the unshared state failover sequence. Detailed configuration information is provided in Configuring Clients for Unshared State Connections.
Detection
Unshared state failover is initiated by the EMS client. When a client setup for unshared state detects a lost connection to server (A), it attempts to connect to server (B), as defined in the connection factory.
Figure 29 Unshared State Failover
Response
Clients with unshared state connections automatically connect to B after losing the connection to A.
When clients setup for unshared state detect lost connections to server A, they create new connections to server, B. All runtime objects from the client's connection are recreated, including sessions, destinations, message producers, and message consumers.
Because unshared state is defined in the connection factory, B remains the current server as long as the connection is active. If the connection to B is lost, clients attempt to connect to another server defined in the connection factory
Message Loss
Because B does not have access to persistent messages that were not delivered or acknowledged prior to the failover, some messages may be lost or delivered out of order across the failover process. To prevent message loss, use shared state failover.
Unsupported Features
These features and Java classes are not supported with unshared state connections:
Dual State Failover
An unshared state connection factory can include shared-state server pairs in its list of backup servers. When both shared state and unshared state servers are included, the failover process is a combination of both types of failover.
Figure 30 illustrates the dual state failover process.
Figure 30 Dual State Failover Process
In this example, servers A1 and A2 share state. Servers B1 and B2 also share state. However, A1 and A2 do not share state with B1 and B2.
The EMS clients created connections using unshared state connection factories. The initial server connections were with server A1. When the connection to A1 failed, the failover process proceeded as described in Shared State Failover Process, and the clients connect to A2.
A2 then failed, before A1 restarted. The clients next created connections to B1, recreating all runtime objects from the connection (as described above in Unshared State Failover Process). B1 is now the current server. Because B1 and B2 share state, If B1 fails, B2 becomes the current server.