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 . 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 will be overwritten
by the application level session settings. If this is not desired,
you can enable WebSphere eXtreme Scale at
the server level.
- In the WebSphere Application Server administrative
console, click .
- 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 .
- 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.
- If you want to edit other aspects of the
HTTP session configuration, you can edit the splicer.properties file. You can get the path location of the splicer.properties file
by locating the sessionFilterProps custom property.
If you configured session persistence at the server level, the name
of the custom property is: :com.ibm.websphere.xs.sessionFilterProps.
If you configured session persistence at the application level, the
name of the custom property is: <application_name>,com.ibm.websphere.xs.sessionFilterProps.
These custom properties might be in one of the following locations:
- In a WebSphere Application Server Network Deployment environment:
The splicer.properties file is on the deployment
manager profile path.
- In a stand-alone WebSphere Application Server environment:
A custom property on the application server
You can open the indicated file, make changes, and synchronize
the nodes so the updated properties file gets propagated to the other
nodes in the configuration. All application server nodes require the splicer.properties file
to be in the specified path to properly persist sessions.Attention: If you want to enable persistence
for sessions that use URL rewriting, set the useURLEncoding property
to true in the splicer.properties file.
For
more information about the properties in the splicer.properties file,
see splicer.properties file.
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.