Configuring WebSphere Application Server HTTP session persistence to a data grid

You can configure your WebSphere® Application Server application to persist sessions to a data grid. This data grid can be in an embedded container server that runs within WebSphere Application Server, or it can be in a remote data grid.

Before you begin

Before you change the configuration in WebSphere Application Server, you must have:

The name of the session data grid that you want to use. See Configuring the HTTP session manager with WebSphere Application Server for information about creating a session data grid.
If the catalog service to manage your sessions is outside of the cell in which you are installing your session application, you must create a catalog service domain. For more information, see Creating catalog service domains in WebSphere Application Server.
If you are configuring a catalog service domain, you might must enable client security on the catalog service domain if the container servers require authentication. These settings inform the run time which CredentialGenerator implementation to use. This implementation generates a credential to pass to the remote data grid. For more information, see Configuring client security on a catalog service domain.
Enable global security in the WebSphere Application Server administrative console, if you support one of these scenarios:
- The catalog servers within your catalog service domain have Secure Sockets Layer (SSL) enabled.
- You want to use SSL for a catalog service domain with SSL supported.
You require SSL for a catalog server by setting the transportType attribute to SSL-Required in the Server properties file. For more information about configuring global security, see Global security settings.
If you are using Version 7.1.0.3 or later, you can persist sessions that use URL rewriting or cookies as a session tracking mechanism to the data grid. For releases before Version 7.1.0.3, you cannot persist sessions that use URL rewriting as a session tracking mechanism. To enable the persistence of sessions that use URL rewriting, set the useURLEncoding property to true in the splicer.properties file after you automatically splice the application.
When you are automatically splicing applications for HTTP session management in WebSphere Application Server , all of the application servers that host the web application have the HttpSessionIdReuse web container custom property that is set to true. This property enables sessions that fail over from one application server to another, or are invalidated from the in-memory session cache in a remote scenario to preserve its session ID across requests. If you do not want this behavior, set the web container custom property to false on all of the applicable application servers before you configure session management for the applications. For more information about this custom property, see Troubleshooting cache integration.

Procedure

To configure session management when you are installing the application, complete the following steps:

In the WebSphere Application Server administrative console, click Applications > New application > New Enterprise Application. Choose the Detailed path for creating the application and complete the initial wizard steps.
In the eXtreme Scale session management settings step of the wizard, configure the data grid that you want to use.
Choose either the Remote eXtreme Scale data grid or the Embedded eXtreme Scale data grid.
- For the Remote eXtreme Scale data grid option, choose the catalog service domain that manages the session data grid, and choose a data grid from the list of active session data grids.
- For the Embedded eXtreme Scale data grid option, choose either the default ObjectGrid configuration or specify the specific location of your ObjectGrid configuration files.
Complete the wizard steps to finish installing your application.

You can also install the application with a wsadmin script. In the following example, the -SessionManagement parameter creates the same configuration that you can in the administrative console:

For the remote eXtreme Scale data grid configuration:

AdminApp.install('C:/A.ear', '[  -nopreCompileJSPs -distributeApp 
-nouseMetaDataFromBinary -nodeployejb -appname A -edition 8.0 
-createMBeansForResources -noreloadEnabled -nodeployws -validateinstall 
off -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 
-buildVersion Unknown -noallowDispatchRemoteInclude -noallowServiceRemoteInclude 
-asyncRequestDispatchType DISABLED -nouseAutoLink -SessionManagement [[true 
XSRemoteSessionManagement cs0:!:grid0]] 
-MapWebModToVH [[MicroWebApp microwebapp.war,WEB-INF/web.xml default_host] [MicroSipApp 
microsipapp.war,WEB-INF/web.xml default_host] [MicroDG1App microdg1app.war,WEB-INF/web.xml 
default_host] [MicroDG2App microdg2app.war,WEB-INF/web.xml default_host] [MicroSip2App 
microsip2app.war,WEB-INF/web.xml default_host]]]')

For the eXtreme Scale embedded scenario with default configuration:

AdminApp.install('C:/A.ear', '[  -nopreCompileJSPs -distributeApp 
-nouseMetaDataFromBinary -nodeployejb -appname A -edition 8.0 
-createMBeansForResources -noreloadEnabled -nodeployws -validateinstall 
off -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 
-buildVersion Unknown -noallowDispatchRemoteInclude -noallowServiceRemoteInclude 
-asyncRequestDispatchType DISABLED -nouseAutoLink -SessionManagement [[true 
XSRemoteSessionManagement  :!: :!:default]]  -MapWebModToVH [[MicroWebApp microwebapp.war,
WEB-INF/web.xml default_host] [MicroSipApp 
microsipapp.war,WEB-INF/web.xml default_host] [MicroDG1App microdg1app.war,WEB-INF/web.xml 
default_host] [MicroDG2App microdg2app.war,WEB-INF/web.xml default_host] [MicroSip2App 
microsip2app.war,WEB-INF/web.xml default_host]]]')

For the eXtreme Scale embedded scenario with a custom configuration:

AdminApp.install('C:/A.ear', '[  -nopreCompileJSPs -distributeApp 
-nouseMetaDataFromBinary -nodeployejb -appname A -edition 8.0 
-createMBeansForResources -noreloadEnabled -nodeployws -validateinstall 
off -noprocessEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 
-buildVersion Unknown -noallowDispatchRemoteInclude -noallowServiceRemoteInclude 
-asyncRequestDispatchType DISABLED -nouseAutoLink -SessionManagement [[true 
XSRemoteSessionManagement  :!: :!:custom:!:c:\XS\objectgrid.xml:!:c:\XS\objectgriddeployment.xml]] 
-MapWebModToVH [[MicroWebApp microwebapp.war,WEB-INF/web.xml default_host] [MicroSipApp 
microsipapp.war,WEB-INF/web.xml default_host] [MicroDG1App microdg1app.war,WEB-INF/web.xml 
default_host] [MicroDG2App microdg2app.war,WEB-INF/web.xml default_host] [MicroSip2App 
microsip2app.war,WEB-INF/web.xml default_host]]]')

To configure session management on an existing application in the WebSphere Application Server administrative console:
Note: The Override session management box is checked when the application is set to use WebSphere eXtreme Scale. This means any server level session settings that were made to WebSphere Application Server configuration are overwritten by the application-level session settings. If you do not want to override settings, you can enable WebSphere eXtreme Scale at the server level.
1. In the WebSphere Application Server administrative console, click Applications > Application Types > WebSphere enterprise applications > application_name > Web Module properties > Session management > eXtreme Scale session management settings.
2. Update the fields to enable session persistence to a data grid.
You can also update the application with a wsadmin script. In the following example, the -SessionManagement parameter creates the same configuration that you can in the administrative console:
For the remote eXtreme Scale data grid configuration:
AdminApp.edit('DefaultApplication','[-SessionManagement[[true XSRemoteSessionManagement cs0:!:grid0]]]')
The :!: characters that are passed are used as delimiters. The values that are passed are:
catalogServiceName:!:gridName
For the eXtreme Scale embedded scenario with default configuration:
AdminApp.edit('DefaultApplication','[-SessionManagement[[true XSEmbeddedSessionManagement :!:!:!:default]]]')
The :!: characters that are passed are used as delimiters. The values that are passed are:
catalogServiceName:!:gridName:!:default:!: absolutePath_to_objectGridXmlfile:!:absolutePath_to_DeploymentXmlfile
For the eXtreme Scale embedded scenario with a custom configuration:
AdminApp.edit('DefaultApplication','[-SessionManagement[[true XSEmbeddedSessionManagement :!:!:!:custom:!:c:\XS\objectgrid.xml:!:c:\XS\objectgriddeployment.xml]]]')
The :!: characters that are passed are used as delimiters. The values that are passed are:
catalogServiceName:!:gridName:!:custom:!: absolutePath_to_objectGridXmlfile:!:absolutePath_to_DeploymentXmlfile
When you save the changes, the application uses the configured data grid for session persistence on the appliance.

To configure session management on an existing server:

In the WebSphere Application Server administrative console, click Servers > Server Types > WebSphere application servers > server_name > Session management > eXtreme Scale session management settings.
Update the fields to enable session persistence.

You can also configure session management on an existing server with the following wsadmin tool commands:

For the remote eXtreme Scale data grid configuration:

AdminTask.configureServerSessionManagement('[-nodeName IBM-C77EE220EB6Node01 -serverName server1 
-enableSessionManagement true -sessionManagementType XSRemoteSessionManagement -XSRemoteSessionManagement 
[-catalogService cs0 -csGridName grid0]]')

For the eXtreme Scale embedded configuration:

The default configuration, if you are using the default XML files:

AdminTask.configureServerSessionManagement('[-nodeName IBM-C77EE220EB6Node01 -serverName server1 
-enableSessionManagement true -sessionManagementType XSEmbeddedSessionManagement 
-XSEmbeddedSessionManagement [-embeddedGridType default -objectGridXML -objectGridDeploymentXML ]]')

The custom configuration, if you are using customized XML files:

AdminTask.configureServerSessionManagement('[-nodeName IBM-C77EE220EB6Node01 -serverName server1 
-enableSessionManagement true -sessionManagementType XSEmbeddedSessionManagement 
-XSEmbeddedSessionManagement 
[-embeddedGridType custom -objectGridXML c:\XS\objectgrid.xml -objectGridDeploymentXML 
c:\XS\objectgriddeployment.xml]]')

When you save the changes, the server now uses the configured data grid for session persistence with any applications that are running on the server.

Results

You configured HTTP session manager to persist the sessions to a data grid. Entries are removed from the data grid when the sessions time out. See Session management settings for more information about updating the session timeout value in the WebSphere Application Server administrative console.