HTTP session failover

In a clustered environment, all requests for a particular session are directed to the same server instance in the cluster. The user is served by the same server instance for the duration of 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.

The global settings portlet displays the node name of the server handling requests.

Failover and lost data

Data stored within the JVM memory and not managed by the application server or the WebSphere Portal server for replication might be lost in the case of failover. Even with the distributed session support, during a failure, users will not be able to recover any uncommitted information that is not stored in sessions or other replicated data areas (such as a distributed Map or render parameters). if we are attempting to deploy a portlet when a failover occurs, the deployment might not be successful, in which case you must redeploy the portlet. 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. The user should log out and log back in to resume normal operation.

Post failover, requests are redirected to another cluster member by the Web server plug-in. To ensure that the browser does not send the same data multiple times without the user's knowledge, most browsers will issue a GET request as a response to a redirect after submitting a POST request. This means that after failover, if a portlet or application uses POST data, users might have to refresh the page in the browser, or go back and resubmit the form to recover the POST data.

Failover considerations for the authoring portlet

We can configure which session attributes are replicated, and how often the replication takes place. Tuning levels range from "Very high", to optimize performance, to "Low" for optimizing failover. If the write frequency is set as "Time-based" with a frequency of 10 seconds, changes to the authoring portlet session within 10 seconds of the failover will be lost. If write frequency is set as "End of the servlet service", the session remains intact after failover.

During a failover condition, a WCM user might be placed back at the initial navigation screen, might have to refresh the browser window. Uncommitted data that is not stored in sessions or other replicated data areas may be lost. However, apart from these issues, there should be no loss of service and the user should be able to continue working.

Parent: Cluster considerations