Configuring the HTTP session manager for various application servers

WebSphere® eXtreme Scale is bundled with a session management implementation that overrides the default session manager for a web container. This implementation provides session replication, high availability, better scalability, and configuration options. You can enable the WebSphere eXtreme Scale session replication manager and generic embedded ObjectGrid container startup for various application servers such as Tomcat.

About this task

You can use the HTTP session manager with other application servers that are not running WebSphere Application Server, such as WebSphere Application Server Community Edition. To configure other application servers to use the data grid, you must splice your application and incorporate WebSphere eXtreme Scale Java archive (JAR) files into your application.

Procedure

  1. Splice your application so that it can use the session manager.
    To use the session manager, you must add the appropriate filter declarations to the web deployment descriptors for the application. In addition, session manager configuration parameters are passed in to the session manager in the form of servlet context initialization parameters in the deployment descriptors. There are three ways in which you can introduce this information into your application:
    • addObjectGridFilter script: For more information, see Splicing a session data grid application with the addObjectGridFilter script.
    • Ant build script:

      WebSphere eXtreme Scale ships with a build.xml file that can be used by Apache Ant, which is included in the was_root/bin folder of a WebSphere Application Server installation. You can modify the build.xml file to change the session manager configuration properties. The configuration properties are identical to the property names in the splicer.properties file. After the build.xml file has been modified, invoke the Ant process by running ant.sh, ws_ant.sh (UNIX) or ant.bat, ws_ant.bat (Windows).

    • Update the web descriptor manually:

      Edit the web.xml file that is packaged with the web application to incorporate the filter declaration, its servlet mapping, and servlet context initialization parameters. Do not use this method because it is prone to errors.

    For a list of the parameters that you can use, see Servlet context initialization parameters.
  2. Incorporate the WebSphere eXtreme Scale session replication manager JAR files into your application.
    You can embed the files into the application module WEB-INF/lib directory or in the application server classpath. The required JAR files vary depending on the type of containers that you are using:
    • Remote container servers: ogclient.jar and sessionobjectgrid.jar
    • Embedded container servers: objectgrid.jar and sessionobjectgrid.jar
  3. Optional: If you use remote container servers, start the container servers.
    See Starting a stand-alone catalog service that uses the ORB transport[Version 8.6 and later]or Starting a stand-alone catalog service that uses the IBM eXtremeIO (XIO) transport for details.
  4. Deploy the application.
    Deploy the application with your normal set of steps for a server or cluster. After you deploy the application, you can start the application.
  5. Access the application.
    You can now access the application, which interacts with the session manager and WebSphere eXtreme Scale.

What to do next

You can change a majority of the configuration attributes for the session manager when you instrument your application to use the session manager. These attributes include variations to the replication type (synchronous or asynchronous), in-memory session table size, and so on. Apart from the attributes that can be changed at application instrumentation time, the only other configuration attributes that you can change after the application deployment are the attributes that are related to the WebSphere eXtreme Scale server cluster topology and the way that their clients (session managers) connect to them.
Remote scenario behavior: If the entire data grid that is hosting the application session data is unreachable from the web container client, the client instead uses the base web container of the application server for session management. The data grid might be unreachable in the following scenarios:
  • A network problem between the Web container and the remote container servers.
  • The remote container server processes have been stopped.
The number of session references kept in memory, specified by sessionTableSize parameter, is still maintained when the sessions are stored in the base web container. The least recently used sessions are invalidated from the web container session cache when the sessionTableSize value is exceeded. If the remote data grid becomes available, sessions that were invalidated from the web container cache can retrieve data from the remote data grid and load the data into a new session. If the entire remote data grid is not available and the session is invalidated from the session cache, the user session data is lost. Because of this issue, do not shut down the entire production remote data grid when the system is running under load.