Session management support
WAS provides facilities, grouped under the heading Session Management, that support the javax.servlet.http.HttpSession interface.
The Session Management facility supports session scoping by Web module. Only servlets in the same Web module can access the data associated with a particular session. Multiple requests from the same browser, each specifying a unique Webapp, result in multiple sessions with a shared session ID. One can invalidate any of the sessions that share a session ID without affecting the other sessions.
One can configure a session timeout for each Webapp. A Webapp timeout value of 0 (the default value) means that the invalidation timeout value from the Session Management facility is used.
When an HTTP client interacts 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. Session Management 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 or URL rewriting techniques. Session Management can store session-related information in several ways:
- In appserver memory (the default). This information cannot be shared with other application servers.
- In a database. This storage option is known as database persistent sessions.
- In another WAS instance. This storage option is known as memory-to-memory sessions.
The last two options are referred to as distributed sessions. Distributed sessions are essential for using HTTP sessions for failover facility. When an appserver receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory). If distributed session support is not enabled, an application server cannot access session information for HTTP requests that are sent to servers other than the one where the session was originally created. Session Management implements caching optimizations to minimize the overhead of accessing the external store, especially when consecutive requests are routed to the same application server.
Storing session states in an external store also provides a degree of fault tolerance. If an appserver goes offline, the state of its current sessions is still available in the external store. This availability enables other application servers to continue processing subsequent client requests associated with that session.
Saving session states to an external location does not completely guarantee their preservation in case of a server failure. For example, if a server fails while it is modifying the state of a session, some information is lost and subsequent processing using that session can be affected. However, this situation represents a very small period of time when there is a risk of losing session information.
The drawback to saving session states in an external store is that accessing the session state in an external location can use valuable system resources. Session Management can improve system performance by caching the session data at the server level. Multiple consecutive requests that are directed to the same server can find the required state data in the cache, reducing the number of times that the actual session state is accessed in external store and consequently reducing the overhead associated with external location access.
Distributed sessions
Sessions
Configure session management by level
Managing HTTP sessions
Managing HTTP sessions: Links: