6.8 HTTP session management
One of the other important functions that the plug-in provides, in addition to failover and workload management, is the ability to manage HTTP sessions.
In many Web applications, users move through the site based on a series of selections on pages they visit. Where the user goes next, and what the application displays as the user's next page (or next choice) may depend on what the user has chosen previously from the site. For example, if the user clicks the checkout button on a site, the next page must contain the user's shopping selections.
In order to do this, a Web application needs a mechanism to hold the user's state information over a period of time. However, HTTP alone does not recognize or maintain a user's state. HTTP treats each user request as a discrete, independent and stateless interaction.
The Java servlet specification proposes a mechanism for servlet applications to maintain a user's state information across multiple user hits. This mechanism, known as a session, allows a Web application developer to maintain all user state information at the host, while exchanging only minimal information with a user's HTTP browser (mostly only session identification data).
Since the Servlet 2.3 specification, as implemented by WAS V5.0 and higher, only a single cluster member may control/access a given session at a time. After a session has been created, all following requests need to go to the same appserver that created the session. This session affinity is provided by the plug-in. (Session affinity)
If this appserver is unavailable when the plug-in attempts to connect to it, the plug-in will choose another cluster member and attempt a connection. Once a connection to a cluster member is successful, the session manager will decide what to do with the session. The cluster member will find that it does not have the session cached locally and thus will create a new session.
To avoid the creation of a new session, a distributed session can be used to access sessions from other appservers.
There are two mechanisms to configure distributed sessions in WAS V6:
- Database persistence
Session state is persisted to a database shared between the clustered appservers. This feature was the only session persistence mechanism provided by earlier versions of WAS (pre-V5.0).
- Memory-to-memory replication
Based on DRS (Data Replication Services), a feature that has been much simplified in WAS V6. It provides in-memory replication of session state between clustered appservers.
See Database session management configuration and Memory-to-memory replication configuration.
The methods used to manage the sessions are very important in a workload-managed environment. There are different methods of identifying, maintaining affinity, and persisting the sessions; these are described in detail in the following sections.