WebSphere Portal v6 - Configure for HTTP session failover

 

+
Search Tips   |   Advanced Search

 

Enable HTTP session failover in the cluster to enable multiple cluster members to serve data in the event that one of them fails.

In a clustered environment, all requests for a particular session are directed to the same WebSphere Portal server instance in the cluster. In other words, after a user establishes a session with a portal (for example, by logging in to the portal), the user is served by the same WebSphere Portal server instance for the duration of the session.

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.

If one of the WebSphere Portal servers in the cluster fails, the request is rerouted to another WebSphere Portal server in the cluster. If distributed sessions support is enabled (either by persistent sessions or memory-to-memory session replication), the new server can access session data from the database or another WebSphere Portal server instance.

Distributed session support is not enabled by default and must be configured separately in WebSphere Application Server.

By default failover support is available for WebSphere Portal and any portlets that are installed with the product. To take advantage of failover support with your own developed portlets, ensure that the portlets are implemented according to best practices.

 

Failover and lost data

Data that is 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).

In such cases, users might have to restart a transaction after a failover occurs. For example, if you are in the process of working with a portlet and have navigated between several different screens when a failover occurs, you might be placed back at the initial screen, where you would need to repeat the previous steps. Similarly, if you are attempting to deploy a portlet when a failover occurs, the deployment might not be successful, in which case redeploy the portlet. Note, however, that with distributed session support enabled, the validity of user login sessions is maintained despite node failures.

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 by the portlet before the failover could disappear after the failover occurs, or the portlet might not work as expected. In such extreme cases, the user should log out and log back 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 will issue a GET request as a response to a redirect after submitting a POST request. This ensures that the browser does not send the same data multiple times without the user's knowledge. However, this means that after failover, users might have to refresh the page in the browser or go back and resubmit the form to recover the POST data.

Document Manager portlets supplied with WebSphere Portal and any other portlets that use POST data are affected by this behavior.

 

Parent topic:

Clustering and WebSphere Portal