HTTP session failover

In a clustered environment, all requests for a particular session are directed to the same server instance in the cluster. After a user establishes a session (for example, by logging in), the user is served by the same server instance during the session. If one of the servers in the cluster fails, the request is rerouted to another server in the cluster. If distributed sessions support is enabled, the new server can access session data from the database or another server instance. Distributed session support must be configured separately in WebSphere Application Server.

For non-clustered servers, to verify which server is handling user requests for a session, use the global settings portlet, which displays the node name of the server handling requests.

Failover and lost data

Data stored is within the JVM memory. Users cannot recover uncommitted information that is not stored in sessions or other replicated data areas. The validity of user login sessions is maintained despite node failures with distributed session support enabled.

In cases where a portlet does not support failover, a "Portlet unavailable" message is displayed for the portlet after a failover occurs. If a portlet supports partial or incomplete failover, some data displayed before the failover might disappear after the failover occurs. The portlet might not work as expected. In such extreme cases, the user must log out and in to resume normal operation.

After a failover occurs, the request is redirected to another cluster member by the web server plug-in. Most browsers issue a GET request as a response to a redirect after you submit a POST request. It ensures the browser does not send the same data multiple times without the user's knowledge. However, this means that after failover, users must refresh the page or resubmit the form to recover the POST data.

Any portlets or applications that use POST data are affected by this behavior.

Failover for the Authoring Portlet

When we configure distributed session support in WebSphere Application Server, either for persistent sessions or memory-to-memory session replication, we can configure the Custom tuning parameters setting to determine which session attributes are replicated, and how often the replication takes place. We can select a tuning level from "Very high" to optimize for performance to "Low" to optimize for failover.

In order for session information to be preserved after failover, set the custom-tuning level so that all session attributes are written.

If the write frequency is set as "Time-based" with a frequency of 10 seconds, changes within 10 seconds of the failover are lost. If the write frequency is set as "End of the servlet service", the Authoring Portlet session remains intact after failover.

During a failover condition, a Web Content Manager user might return to the initial screen. They must refresh the browser window. Uncommitted data that is not stored in sessions or other replicated data areas are lost. However, apart from these issues, there is no loss of service and the user can continue to work.

Parent Cluster considerations