To configure your WebSphere® Application
Server application to use the appliance
for session management, you can either select the appliance when you
are installing a new application, or you can update your existing
application or server settings to use the appliance.
Before you begin
Before you change the configuration in
WebSphere Application
Server, you must have:
- Access to the WebSphere Application
Server cell
that you want to configure.
- The IP address or fully-qualified
host name of the appliance.
- A User ID and password that you
use to log in to the appliance user interface.
To create a data grid,
you must have data cache creation permissions.
- WebSphere eXtreme
Scale Client installed in
your WebSphere Application
Server configuration. See Installing WebSphere eXtreme Scale Client for more information.
- Global
security enabled in the WebSphere Application
Server administrative
console, if your appliance has transport layer security enabled or
you want to ensure that clients use transport layer security. See Configuring Transport Layer Security (TLS) for more information.
- Only
sessions that use cookies as the session tracking mechanism
can be saved to the data grid. You cannot persist sessions that use
URL rewriting as a session tracking mechanism.
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. For
the Manage session persistence by field, choose WebSphere DataPower XC10 Appliance. Enter the information
about the appliance and the data grid on
the appliance that you want to use. You can either create a new data grid or use an existing data grid that you have already
configured on the appliance.
If you want to save your sessions in
an existing data grid on the
appliance, you should know the name of the data grid that you want to use.
However, you also have the option to create a new data grid on the appliance when
you configure your application. If you want to create a session data grid before configuring the
application in the WebSphere Application
Server administrative
console, click . Click the add icon (
) and specify a name for the session data grid
that you want to create. The following characters cannot be used in
the name of the data grid: ^ . \\ / , # $ @ : ; \ * ? <
> | = + & % [ ] " ".
- 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:
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
XC10SessionManagement myXC10.ibm.com:!:username:!:password:!:AGrid80]]
-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:
- 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:
AdminApp.edit('A-edition9.0', '[ -SessionManagement [[true
XC10SessionManagement myXC10.ibm.com:!:username:!:password:!:AGrid80]]]')
The
:!: characters that
are passed are used as delimiters. The values that are passed are:
applicationIdentifier:!:username:!:password:!:
gridName
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:
AdminTask.configureServerSessionManagement('[-nodeName my_node
-serverName server1 -enableSessionManagement true -sessionManagementType
XC10SessionManagement -XC10SessionManagement [-applianceIdentifier myserver.ibm.com
-userName -password ******** -gridName myTestGrid]]')
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.
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 in
WebSphere Application
Server for session management.
The data grid might be unreachable in the following scenarios:
- A
network problem between the Web container and the appliance.
- The
server processes on the appliance have been stopped.
The
least recently used sessions are invalidated from the web
container session cache. If the data grid on the appliance 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 data grid on the appliance 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 entire production
data grid when the system is running under load.
CAUTION:
When you configure this scenario,
the security credentials for the IBM WebSphere DataPower XC10 Appliance are automatically
stored in the WebSphere Application
Server configuration.
If you change the credentials for the data grid after the initial
configuration, the WebSphere Application
Server no
longer has the correct credentials. You can reset the credentials
by applying the eXtreme Scale session management settings again.
What to do next
- Configure security before you
begin to send data to the data grid.
See Securing data grids for more information.
- Configure replicas. Replicas ensure that your data grid data is
available if the primary copy fails. To configure replicas, click . Replicas
are created only when the appliance is in a collective. If the number
of appliances in the collective is n, the maximum
number of replicas is n-1. Therefore if you configure
three replicas, but you only have two appliances in the collective,
only one replica is created. Additional replicas are created if you
add appliances to the collective. Set the number of replicas to the
ideal amount that you want to have, so that as appliances join the
collective, new replicas can be created. The data grid content is
cleared when you edit the number of replicas.
- Configure
a capacity limit for the data grid.
By configuring capacity limits on the data grid, you can ensure that
the storage capacity for the collective is used in a predictable manner.
See Configuring the maximum capacity of a data grid for more information.
- You can monitor your session bdata grid in the DataPower XC10
Appliance user interface. See Monitoring data grids in the user interface for more information.