WebSphere eXtreme Scale Administration Guide > Configure WebSphere eXtreme Scale > Cache integration

HTTP session management

In a WebSphere Application Server Version 5 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 WebSphere Application Server Version 6.0.2 or later or in an environment that is not running WebSphere Application Server, such as WebSphere Application Server Community Edition or Apache Tomcat.

Features

The session manager has been designed so that it can run in any Java™ Platform, Enterprise Edition Version 1.4 container. The session manager does not have any dependencies on WebSphere APIs, so it is capable of supporting various versions of WebSphere Application Server 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 JavaServer Pages (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 WebSphere Application Server, 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 WebSphere Application Server. 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.

Retrive 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.

• Configure the HTTP session manager with WebSphere Application Server
  While WebSphere Application Server provides session management function, this support does not scale under extreme request loads. WebSphere eXtreme Scale comes bundled with a session management implementation that overrides the default session manager for a Web container and provides better scalability and more robust configuration options.

• Configure the HTTP session manager with WebSphere Application Server Community Edition
  WebSphere Application Server Community Edition can share session state, but not in an efficient, scalable manner. WebSphere eXtreme Scale provides a high performance, distributed persistence layer that can be used to replicate state, but does not readily integrate with any application server outside of WebSphere Application Server. You can integrate these two products to provide a scalable session-management solution. You can use the WebSphere Application Server Community Edition modular infrastructure, GBeans, to embed WebSphere eXtreme Scale as the session-state persistence mechanism.

• Servlet context initialization parameters
  The following list of servlet context initialization parameters can be specified in the properties file as required in the script or ANT-based splicing methods.

Parent topic

Cache integration

Related tasks

Configure the HTTP session manager with WebSphere Application Server

Configure the HTTP session manager with WebSphere Application Server Community Edition

Related reference

Servlet context initialization parameters

+

Search Tips   |   Advanced Search