Administration guide > Configure the deployment environment > Configuring cache integration > Configuring HTTP session managers
Configure the HTTP session manager with WAS
Before you begin
While WAS provides session management function, this support does not scale under extreme request loads. WXS comes bundled with a session management implementation that provides...
WXS must be installed on the WAS or WAS ND cell to use the WXS session manager.
If the catalog servers within the catalog service domain have SSL enabled, global security must be enabled in the WAS administrative console. SSL is required for a catalog server by setting the transportType attribute to SSL-Required in the Server properties file.
In the embedded scenario, the WXS servers are collocated in the same processes where the servlets run. The session manager can communicate directly with the local ObjectGrid instance, avoiding costly network delays.
If you are using WAS, place the supplied files...
...into the META-INF directories of the Web archive (WAR) files.
WXS automatically detects these files when the application starts and automatically starts the WXS containers in the same process as the session manager.
Modify objectGridDeployment.xml to set...
- Synchronous or asynchronous replication
- How many replicas to configure
Remote servers scenario
In the remote servers scenario, the container servers run in different processes than the servlets. The session manager communicates with a remote container server.
To use a remote, network-attached container server, the session manager must be configured with the host names and port numbers of the catalog service domain. The session manager then uses an WXS client connection to communicate with the catalog server and the container servers.
If the container servers are starting in independent, stand-alone processes, start the WXS containers using...
...supplied in the session manager samples directory.
- To use the session manager, add filter declarations to the application's Web deployment descriptors
Session manager configuration parameters are passed in to the session manager in the form of servlet context initialization parameters.
Ways to add this information to the application include...
- Auto-splice with WAS
- Configure the app to use WXS HTTP session manager when installing the app.
- Edit the application or server configuration to use the WXS HTTP session manager
- Auto-splice the application with custom properties
You do not need to manually splice the applications when the application is running in WAS or WAS ND.
Add a custom property to either a cell or a server to set splicer.properties for all of the Web applications at that scope. The property name is...
...and set value to the location of the splicer.properties file your applications require.
The following is an example path for the location of a file:
To configure the custom property...
- In the WAS administrative console, navigate to the correct path for where to set the custom property to indicate the location of splicer.properties.
- To set the custom property for all applications or a specific application...
System administration | Cell | Custom properties
- To set the custom property to apply to all the applications on a specific application server, click...
Application server | <server_name> | Administration | Custom properties
- To set the location of splicer.properties to edit, add the property...
The file exists on the deployment manager.
To set splicer.properties for a specific application using a cell-level custom property, enter the name of the custom property as:
- Edit splicer.properties that is in the path for the custom property on the deployment manager profile.
- Synchronize the nodes so the updated splicer.properties file is propagated to the nodes...
System Administration | Nodes | NodeName | Synchronize
Ensure the updated splicer.properties is located at the same path on all nodes containing an application server hosting the application or applications that are being spliced for session replication."
The cell, server, and application scope are available scopes and are only available when running in a deployment manager. If you require a different scope, you should manually splice the Web applications.
Remember: Also, note that the auto-splice option works only if all of the nodes running the application contain splicer.properties at the same path. For mixed environments containing Windows and UNIX nodes, this option is not possible, so manually splice the application.
- Splice the application with the addObjectGridFilter script
Use a command line script provided along with WXS to splice an application with filter declarations and configuration in the form of servlet context initialization parameters. For a WAS deployment, this script is located in...
For a stand-alone deployment, the script is at...
WXS_HOME/ObjectGrid/session/bin/addObjectGridFilter.shThe oddObjectGridFilter script takes two parameters:
- Application - absolute path to the enterprise archive file that needs to be spliced
- Absolute path to the properties file that contains various configuration properties.
The usage format of this script is...
addObjectGridFilter.sh [location of ear file] [location of properties file]>
Example using WXS installed on WAS on Unix:
./addObjectGridFilter.sh /tmp/mySessionTest.ear was_root/optionalLibraries/ObjectGrid/session/samples/splicer.properties
Example using WXS installed in a stand-alone directory on Unix:
./addObjectGridFilter.sh /tmp/mySessionTest.ear >wxs_home/session/samples/splicer.properties
The servlet filter that is spliced in maintains defaults for configuration values. You can override these default values with configuration options that you specify in the properties file in the second argument.
You can modify and use the sample splicer.properties file that is provided with WXS installation. You can also use the addObjectGridServlets script, which inserts the session manager by extending each servlet. However, the recommended script is the addObjectGridFilter script.
- Manually splice the application with the Ant build script
WXS ships with a build.xml file that can be used by Apache Ant, which is included in...
The build.xml can be modified to change the session manager configuration properties. The configuration properties are identical to the property names in splicer.properties. After the build.xml has been modified, invoke the Ant process by running:
- Manually update the Web descriptor
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. You should 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.
- Deploy the application.
Deploy the application with the normal set of steps for a server or cluster. After you deploy the application, you can start the application.
- Access the application.
You can now access the application, which interacts with the session manager and WXS.
What to do next
You can change a majority of the configuration attributes for the session manager when you instrument the application to use the session manager. These attributes include:
- synchronous or asynchronous replication
- session ID length
- in-memory session table size
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 WXS server cluster topology and the way that their clients (session managers) connect to them.
- Automatically splicing applications for HTTP session management in WAS
You can configure the WAS application to persist sessions to a data grid. This data grid can be in an embedded container server that runs within WAS, or it can be in a remote data grid.
- splicer.properties file
splicer.properties contains all of the configuration options for configuring a servlet-filter-based session manager.
- Use WebSphere WXS for SIP session management
Use WXS as a SIP replication mechanism as a reliable alternative to the data replication service (DRS) for SIP session replication.
Parent topic:Configure HTTP session managers
Configure HTTP session manager with WebSphere Portal
Configure the HTTP session manager for various application servers
XML files for HTTP session manager configuration
Servlet context initialization parameters