HTTP session failover
In a clustered environment, all requests for a particular session are directed to the same 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 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, which displays the node name of the server handling requests. 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 (either by persistent sessions or memory-to-memory session replication), the new server can access session data from the database or another server instance.
Distributed session support must be configured separately in WAS. Refer to the WAS documentation for information:
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 own developed portlets, ensure that 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 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. 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 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. Any portlets or applications that use POST data are affected by this behavior.
Failover considerations for the Web Content Authoring Portlet
When configuring distributed session support in WAS, either for persistent sessions or memory-to-memory session replication, you can configure the Custom tuning parameters setting to determine which session attributes are replicated and how often the replication takes place. You 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 when using the Web Content Authoring Portlet, the custom tuning level should be set so that all session attributes are written.
For example, if the write frequency is set as "Time-based" with a frequency of 10 seconds, any changes to the Web Content Authoring Portlet session within 10 seconds of the failover will be lost. If the write frequency is set as "End of the servlet service", the Web Content Authoring Portlet session will remain intact after failover.
During a failover condition, a Web Content Management 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