Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
Configure for HTTP session failover
Enable HTTP session failover in your 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 Express server instance in the cluster. In other words, after a user establishes a session (for example, by logging in), the user is served by the same WebSphere Portal Express server instance for the duration of the session. To verify which server is handling user requests for a session, you can view the global settings portlet in WebSphere Portal Express, which displays the node name of the WebSphere Portal Express server handling requests.
If one of the WebSphere Portal Express servers in the cluster fails, the request is rerouted to another WebSphere Portal Express 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 Express server instance.
Distributed session support is not enabled by default and must be configured separately in WebSphere Application Server. Refer to the WebSphere Application Server documentation for information:
- Windows and Linux: Distributed sessions
- i5/OS:
By default failover support is available for WebSphere Portal Express and any portlets that are installed with the product. To take advantage of failover support with a developed portlets, ensure that your 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 Express 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 your 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 Express and any other portlets that use POST data are affected by this behavior.