HTTP sessions and the session management facility
In the case of an HTTP client interacting with a servlet, the state information associated with a series of client requests is represented as an HTTP session, and identified by a session ID. The session manager module that is part of each Web container is responsible for managing HTTP sessions, providing storage for session data, allocating session IDs, and tracking the session ID associated with each client request, through the use of cookies, URL rewriting, or SSL ID techniques.
The session manager provides for the storage of session-related information either in-memory within the appserver, in which case it cannot be shared with other application servers; in a back-end database, shared by all application servers; or by using memory-to-memory replication.
The second option, sometimes referred to as persistent sessions or session clustering, is one method that uses HTTP sessions with the load-distribution configuration. With this option, whenever an appserver receives a request associated with a session ID, which is not in memory, it can obtain it by accessing the back-end database, and can then serve the request. When this option is not enabled, and another clustering mechanism is not used, if any load-distribution mechanism happens to route an HTTP request to an application server other than the one where the session was originally created, that server would be unable to access the session, and would thus not produce correct results in response to that request. One drawback to the database solution is that it provides a single point of failure (SPOF) that must be architected for with other products such as HACMP solutions and database replication. Another drawback is the performance hit, caused by database disk I/O operations and network communications.
The last option, memory-to-memory replication, provides a new mechanism for session clustering within IBM WAS Network Deployment V5. It uses the built-in Data Replication Service (DRS) of WebSphere V5 to replicate session information stored in memory to other members of the cluster. Using this functionality removes the single point of failure that is present in persistent sessions through a database solution that has not been made highly available using clustering software. The sharing of session state is handled by creating an internal replication domain, adding replication entries, and then configuring the Web container to use the domain entries and the replication for session state information.
The latest performance measurements showed that the overhead associated with replicating the session to every other cluster member is more significant than contention introduced by using the database session repository (the more appservers in the cluster, the more overhead for memory-to-memory replication). However, these measurements were taken using the default memory-to-memory session replication configuration (that is peer-to-peer) which is not an optimal configuration.
Memory-to-memory replication performance can be greatly improved by using/configuring:
- Replication domains
- Domain partitioning
- DRS connection pooling
- Client/Server replication
For larger session sizes the overhead of session replication increases. Database replication has a lower overall throughput than memory-to-memory due to database I/O limitations (the database becomes the bottleneck). However, while database replication with large sessions performs slower, it is doing so with less CPU power than memory-to-memory replication. The unused processor power can be used by other tasks on the system.
Storing session states in a persistent database or using memory-to-memory replication provides a degree of fault tolerance to the system. If an appserver crashes or stops, any session state that it may have been working on would normally still be available either in the back-end database or in the running application server's memory, so that other application servers can take over and continue processing subsequent client requests associated with that session.
Neither mechanism provides a 100% guarantee that a session state will be preserved in case of a server crash. If a server happens to crash while it is literally in the middle of modifying the state of a session, some updates may be lost and subsequent processing using that session may be affected. Also, in the case of memory replication, if the node crashes during a replication, or in between the time interval that has been set for replicating session information, then some session information may be lost.
However, such a situation represents only a very small window of vulnerability, and a very small percentage of all occurrences that typically happen throughout the life of a system in production.