WebSphere eXtreme Scale Product Overview > Cache integration
HTTP session management
In a WAS V5 or later environment, the HTTP session manager that is shipped with WebSphere eXtreme Scale can override the default session manager in the application server.
The WebSphere eXtreme Scale HTTP session manager can also run on WAS V6.0.2 or later or in an environment that is not running WebSphere Application Server, such as WAS Community Edition or Apache Tomcat.
Features
The session manager has been designed so that it can run in any JEE 1.4 container. The session manager does not have any dependencies on WebSphere APIs, so it is capable of supporting various versions of WAS as well as vendor application server environments.
The HTTP session manager provides session management capabilities for an associated application. The session manager creates HTTP sessions and manages the life cycles of HTTP sessions that are associated with the application. These life cycle management activities include: the invalidation of sessions based on a timeout or an explicit servlet or JSP call and the invocation of session listeners that are associated with the session or the web application. The session manager persists its sessions in an ObjectGrid instance. This instance can be a local, in-memory instance or a fully replicated, clustered and partitioned instance. The use of the latter topology allows the session manager to provide HTTP session failover support when application servers are shut down or end unexpectedly. The session manager can also work in environments that do not support affinity, when affinity is not enforced by a load balancer tier that sprays requests to the application server tier.
Usage scenarios
The session manager can be used in the following scenarios:- In environments that use application servers at different versions of WAS, such as in a classic migration scenario.
- In deployments that use application servers from different vendors. For example, an application that is being developed on open source application servers and that are hosted on WAS. Another example is an application that is being promoted from staging to production. Seamless migration of these application server versions is possible while all HTTP sessions are live and being serviced.
- In environments that require the user to persist sessions with higher quality of service (QoS) levels and better guarantees of session availability during server failover than default WebSphere Application Server QoS levels.
- In an environment where session affinity cannot be guaranteed, or environments in which affinity is maintained by a vendor load balancer and the affinity mechanism needs to be customized to that load balancer.
- In an environment to offload the overhead of session management and storage to an external Java process.
- In multiple cells to enable session failover between cells.
How the session manager works
The session manager introduces itself into the request path in the form of a servlet filter. You can add this servlet filter to every Web module in the application with tooling that ships with WebSphere eXtreme Scale. You can also manually add these filters to the Web deployment descriptor of the application. This filter receives the request before the servlet or JSP files in the target application. At this time, the filter intercepts the HTTPRequest and HTTPResponse objects and creates the respective wrapper objects for its own implementation.
This filter implementation intercepts all HTTP session related calls that are made on the HTTPRequest and HTTPResponse objects. These calls are satisfied by the session manager and are not passed through to the base session manager in the underlying JEE server implementation. The session manager creates and maintains sessions and their life cycles, including timeout-based invalidations and the firing of listeners on session invalidations and other life cycle events.
Figure 1. HTTP session management topology with a remote container configuration
Deployment topologies
The session manager can be configured using two different dynamic deployment scenarios:
- Embedded, network attached eXtreme Scale containers
In this scenario, the eXtreme Scale servers are collocated in the same processes as the servlets. The session manager can communicate directly to the local ObjectGrid instance, avoiding costly network delays.
- Remote, network attached eXtreme Scale containers
In this scenario, the eXtreme Scale servers run in external processes the process in which the servlets run. The session manager communicates with a remote eXtreme Scale server grid.
Retreive an eXtreme Scale session in a session manager application
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
HttpSession session = req.getSession(true);
System.out.println("calling getSession");
// call getAttribute("com.ibm.websphere.objectgrid.session")
// to get the ObjectGrid session instance
Session ogSession = (Session)session.getAttribute
("com.ibm.websphere.objectgrid.session");
System.out.println("ogSession = "+ogSession);
}
Any changes made to the maps with the session that is returned from the getAttribute method call are committed when the underlying session is committed. See the Servlet context initialization parameters for more information.