If you log in with your developerWorks ID, you can leave comments and feedback for the development team.

In a WebSphere Application Server, Version 5 or later environment, the HTTP session manager that is shipped with XD DataGrid 6.1 can override the default session manager in the application server. This topic outlines the procedures to follow in order to get such a setup working, as well as the various topologies/configuration options supported by such an overridden HTTP Session Manager. It also briefly describes the scenarios that may benefit from the use of the XD Session Manager.

Note: The DataGrid Version 6.1 HTTP session manager can run on WebSphere Application Server Version 6.0.2 or later or in a non-WebSphere Application Server environment such as WebSphere Application Server - Community Edition or Apache Tomcat.

The following topics are covered in this article:

Features

The ObjectGrid based XD Session Manager has been designed in such a fashion so that it can run in any J2EE 1.4 container. It does not have any dependencies on WebSphere APIs and as a result is capable of supporting various versions of WebSphere Application Server as well as third-party application server environments.

The HTTP session manager provides session management capabilities for an application that it is associated with. The session manager is responsible for the creation of HTTP sessions as well as managing the life cycle of HTTP sessions belonging to the application. This includes the invalidation of sessions based on timeout or an explicit servlet/jsp call as well as the invocation of session listeners associated with the session and/or the web application.

The XD 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 XD Session manager to provide HTTP Session failover support when application servers are brought down or end unexpectedly.

The XD session manager can also work in environments that do not support affinity. That is, when affinity is not enforced by a load balancer tier that sprays requests to the application server tier.

Usage Scenarios

The previously mentioned features allow the XD session manager to be used in disparate environments such as the following:

• Environments using application servers at different versions of WebSphere (classic migration scenario).
• Deployments using application servers from different vendors. For example; an application being developed on open source application servers and hosted on WebSphere Application Servers or an application being promoted from staging to production. Seamless migration of these is possible while all HTTP sessions are kept live and serviced.
• Environments requiring 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.
• When session affinity cannot be guaranteed, or those in which affinity is maintained by a third party load balancer and the affinity mechanism needs to be customized to that load balancer.
• When customers would like to offload the overhead of session management/storage to an external Java process.
• Customers who would like to have session failover in multi-cell environments.

How does the XD session manager work?

The XD session manager introduces itself into the request path in the form of a servlet filter. This servlet filter is added to every web module in the customer application by tooling that ships with the XD product. These filters can also be manually added into the web deployment descriptor of the customer application towards the same end result. This filter then gets called before the servlet/jsps in the target application on the request path before control is passed to the destination servlet/jsp. At this time, the filter intercepts the HTTPRequest and HTTPResponse object and wrappers them with its own implementation.

This filter implementation intercepts all HTTP session related calls made on the HTTPRequest and HTTPResponse objects. These calls are satisfied by the XD session manager and are not passed through to the base session manager in the underlying J2EE server implementation. The XD session manager creates and maintains sessions and their life cycle, including timeout based invalidations and the firing of listeners on session invalidations and other life cycle events.

ObjectGrid Deployment Topologies

The XD Version 6.1 session manager supports both the static deployment topology used in prior versions of ObjectGrid and the preferred dynamic deployment topology. The XD session manager can be configured using two different dynamic deployment scenarios:

• Embedded, network attached ObjectGrid containers
  In this scenario, the ObjectGrid servers are collocated in the same processes where the servlets run. The XD session manager can communicate directly to the local ObjectGrid instance, avoiding costly network delays.
• Remote, network attached ObjectGrid containers
  In this scenario, the ObjectGrid servers run in external processes from that which the servlets run. The XD session manager communicates to a remote ObjectGrid.

Setting up and configuring the web container/application to use the eXtreme scale session manager

While the code for the session manager is designed to work with any J2EE 1.4 web container, the methodology for fully integrating it into both the web container and/or any web applicaitons is specific to the container being used. Below is a comprehensive list for configuring the session manager to work with specific implementations:

• WebSphere Application Server
• WebSphere Community Edition

Retrieving an ObjectGrid session in an XD session manager application

You can retrieve the underlying ObjectGrid session from within your XD 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 ObjectGrid maps via the session returned from the getAttribute() call will be committed when the underlying session is committed. See the replicationType property for more information on when the session gets committed.

Wiki Disclaimer and License

© Copyright IBM Corporation 2007,2010. All Rights Reserved.