0.11.2: What is session clustering?

The Session Manager session support allows multiple application server instances to share a common pool of sessions, known as a session cluster. A session cluster is the binding of the session to more than one active application server Java virtual machine (JVM) sharing a common HTTP session table.

The implementation of clustering in IBM WebSphere Application Server allows failover. This preserves session data integrity and the common pool of sessions in the event of a system failure in one or more of the clustered JVMs running servlets within a group of servers.

The session clustering implementation also allows load balancing, whereby the session workload is distributed among the JVMs that comprise the cluster.

Session clustering requires an affinity mechanism so that all requests for a particular session are directed to the same Java Virtual Machine (JVM) in the cluster. This conforms to the Servlet 2.2 Specification in that multiple requests for a session cannot coexist in multiple JVMs. One such solution provided by IBM WebSphere Application Server is Session Affinity in a server group; this solution is available as part of the WebSphere plug-ins for Web servers. If one of the servers in the cluster fails, it is possible for the request to be rerouted to another server in the cluster. The new server can access session data from the common SESSIONS table. This is transparent to the servlet, browser, and user.

The same Web application must be present on each of the servers that can access the session. This can be accomplished by installing a Web module into a server group. Each of the servers in the group can then access the Web application; if a persistence mechanism is used, sessions can fail over between servers.

Manually cloned environments (that is, those not in WebSphere server groups) can share session data between servers if the identical Web application is installed with the same virtual host name on each of the servers. These environments also require an affinity mechanism to ensure that the session is active in only one JVM at any given time.

If the JVM fails during the writing of session information in the session database, the update to the database does not get committed. Still, the common pool of sessions continues to function, including the session being processed at the time of failure.

For non-catastrophic failures (such as when the JVM remains functional), any session changes that cannot be completed are rolled back. The session reverts to its state prior to the start of the persistence operation. If instead the write operation is completed successfully and the changes are committed, the session is still accessible, regardless of the failure.