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 modules. 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 Web application, result in multiple sessions with a shared session ID. You can invalidate any of the sessions that share a session ID without affecting the other sessions.
You can configure a session timeout for each Web application. A Web application 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 appservers.
- 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 the 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 appserver 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 appserver.
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 appservers 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.
Related concepts
Distributed sessions
Sessions
Related tasks
Configure session management by level
Task overview: Managing HTTP sessions
Related Reference
HTTP sessions: Resources for learning