Configuring HTTP session manager with WebSphere Portal

You can persist HTTP sessions from WebSphere® Portal into a data grid.

Before you begin

Your WebSphere eXtreme Scale and WebSphere Portal environment must meet the following requirements:

How you install WebSphere eXtreme Scale depends on your deployment scenario. You can run the container servers, which host the data grids, either inside or outside of the WebSphere Application Server cell:
- If you are running container servers in the WebSphere Application Server cell (embedded scenario): Install both the WebSphere eXtreme Scale client and server on your WebSphere Application Server and WebSphere Portal nodes.
- If you are running container servers outside of the WebSphere Application Server cell (remote scenario): Install WebSphere eXtreme Scale Client on your WebSphere Application Server and WebSphere Portal nodes.
See Installing WebSphere eXtreme Scale or WebSphere eXtreme Scale Client with WebSphere Application Server for more information.
WebSphere Portal Version 7 or later.
Custom portlets must be configured within WebSphere Portal. The administrative portlets that come with WebSphere Portal cannot currently be integrated with data grids.

About this task

Introducing WebSphere eXtreme Scale into a WebSphere Portal environment can be beneficial in the following scenarios:

Important: Although the following scenarios introduce benefits, increased processor usage in the WebSphere Portal tier can result from introducing WebSphere eXtreme Scale into the environment.

When session persistence is required.
For example, if the session data from your custom portlets must stay available during a WebSphere Portal Server failure, you can persist the HTTP sessions to the WebSphere eXtreme Scale data grid. Data replicates among many servers, increasing data availability.
In a multiple data center topology.
If your topology spans multiple data centers across different physical locations, you can persist the WebSphere Portal HTTP sessions to the WebSphere eXtreme Scale data grid. The sessions replicate across data grids in the data centers. If a data center fails, the sessions are rolled over to another data center that has a copy of the data grid data.
To lower memory requirements on the WebSphere Portal Server tier.
By offloading session data to a remote tier of container servers, a subset of sessions are on the WebSphere Portal servers. This offload of data reduces the memory requirements on the WebSphere Portal Server tier.

Procedure

Splice the wps WebSphere Portal application and any custom portlets to enable the sessions to be stored in the data grid.

See Configuring WebSphere Application Server HTTP session persistence to a data grid for more information. This action results in the splicing of the custom portlets to enable session persistance to your data grid.

You can splice the application by configuring HTTP session management when you deploy the application, or you can use custom properties to automatically splice your applications. See Configuring the HTTP session manager with WebSphere Application Server for more information about splicing the application.
If you are using the remote scenario, where your container servers are outside of the WebSphere Application Server, explicitly start remote eXtreme Scale containers for remote HTTP session persistence scenarios.
Start the containers with the XS/ObjectGrid/session/samples/objectGridStandAlone.xml and objectGridDeploymentStandAlone.xml configuration files. For example, you might use the following command:
```
startOgServer.sh xsContainer1 -catalogServiceEndPoints <host>:<port> 
-objectgridFile XS/ObjectGrid/session/samples/objectGridStandAlone.xml -deploymentPolicyFile 
XS/ObjectGrid/session/samples/objectGridDeploymentStandAlone.xml
```
```
startXsServer.sh xsContainer1 -catalogServiceEndPoints <host>:<port> 
-objectgridFile XS/ObjectGrid/session/samples/objectGridStandAlone.xml -deploymentPolicyFile 
XS/ObjectGrid/session/samples/objectGridDeploymentStandAlone.xml
```
For more information about starting container servers, see Starting container servers that use the ORB transport or Starting container servers that use the IBM eXtremeIO (XIO) transport. If you are using an embedded scenario, see Configuring container servers in WebSphere Application Server for more information about configuring and starting container servers.
Some versions of WebSphere Portal server can have runtime errors when cookies are added to an HTTP response. Since adds cookies for failover and other purposes, these cookies need to be added to WebSphere Portal server cookie ignore list. For more information, see the cookie.ignore.regex parameter section of Caching pages shared by multiple users on the IBM WebSphere Portal wiki. The two cookies that need to be added to the list are IBMID.* and IBMSessionHandle.*. The updated list may look like this for example "digest\\.ignore.*|LtpaToken|LtpaToken2|JSESSIONID|IBMID.*|IBMSessionHandle.*". For more information, see Caching pages shared by multiple users on the IBM WebSphere Portal wiki.
Restart the WebSphere Portal servers.
See WebSphere Portal Version 7: Starting and stopping servers, deployment managers, and node agents for more information.

Results

You can access the WebSphere Portal Server, and HTTP session data for the configured custom portlets is persisted to the data grid.

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 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’s session data is lost. Because of this issue, you should not shut down the entire production remote data grid when the system is running under load.