If you use the EADs session failover functionality and a session creation processing occurs, the processing is extended and the session information is stored on an EADs server. The EADs server for storing the session information is decided for each Web application.

For details on the EADs, server see the Elastic Application Data store User Guide.

The following figure shows the flow of storing the session information.

Figure 5-9 Flow of storing the session information (the EADs session failover functionality)

No. corresponds to the numbers in the figure.

1. If the Web server receives a request requiring creation of a session from the client, a session is created on the J2EE server.
2. Session information is created for the session.
3. The session information is stored in the session information cache on the EADs server 1 (the session information storage destination server) through the EADs client.
4. The EADs session failover functionality automatically copies the session information stored in the session information cache on EADs server 1 to the session information cache on the EADs server 2 (the session information copy destination server) in the cluster.

Hereafter, the EADs server on which the session information is stored is called a session information storage destination server. The EADs server, onto which the session information stored on the session information storage destination server is copied, is called a session information copy destination server.

If a failure occurs on a Web server or a J2EE server, you can re-create the session on another J2EE server on the basis of the session information stored in the session information cache on the EADs server and continue the normal operations.

The following figure shows the processing when a failure occurs on a J2EE server.

Figure 5-10 Processing when a failure occurs on a J2EE server (the EADs session failover functionality)

1. If a failure occurs on J2EE server 1, load balancer transfers the request to J2EE server 2.
2. Because the session associated with the request does not exist when processing the request on the J2EE server at the transfer destination, the J2EE server inherits the session information from the EADs server 1 (the session information storage destination server).
3. The session is recreated.

The session is successfully inherited and you can continue the operations in the state before failure.

When you restart the J2EE server 1 and J2EE server 1 recovers from failure, the requests are again sent to J2EE server 1.

If a failure occurs on an EADs server, the EADs functionality automatically disconnects the EADs server on which the failure occurred, from the cluster. If the EADs server on which the failure occurred, is a session information storage destination server, a normal EADs server in the cluster (the session information copy destination server) switches as a session information storage destination server. Because the EADs Sever connected from the J2EE server also automatically switches with the switching of the session information storage destination server, you can continue the operation as is.

If the EADs server, on which the failure occurred is a session information copy destination server, you can connect to the session information storage destination EADs server from the J2EE server and thus continue the operation as is.

The following figure shows the processing when a failure occurs on the session information storage destination EADs server.

Figure 5-11 Flow of processing when a failure occurs on an EADs server