Administration guide > Configure the deployment environment > Configuring cache integration > Configuring HTTP session managers
Configure HTTP session manager with WebSphere Portal
You can persist HTTP sessions from WebSphere Portal into a data grid in WebSphere eXtreme Scale.
Before you beginYour WebSphere eXtreme Scale and WebSphere Portal environments must meet the following requirements:
- WebSphere eXtreme Scale Version 7.1 with Fix 1 applied. How you install WebSphere eXtreme Scale depends on the 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 the 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 the WebSphere Application Server and WebSphere Portal nodes.
See Install WebSphere eXtreme Scale or WebSphere eXtreme Scale Client with WAS for more information.
- WebSphere Portal Version 126.96.36.199.
- Custom portlets must be configured within WebSphere Portal. The administrative portlets that come with WebSphere Portal cannot currently be integrated with WebSphere eXtreme Scale data grids.
Introducing WebSphere eXtreme Scale into a WebSphere Portal environment can be beneficial in the following scenarios:
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 the custom portlets must stay available during a WebSphere Portal Server failure, you can persist the HTTP sessions to the WebSphere eXtreme Scale data grid. With WebSphere eXtreme Scale, you can replicate data among many servers, increasing data availability.
- In a multiple data center topology.
If the topology spans multiple data centers across different physical locations, you can persist the WebSphere Portal HTTP sessions to the WebSphere eXtreme Scale data grid. WebSphere eXtreme Scale replicates these sessions 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 WebSphere eXtreme Scale 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.
- Splice the wps WebSphere Portal application and any custom portlets to use the WebSphere eXtreme Scale session manager.
You can splice the application by configuring HTTP session management when you deploy the application, or you can use custom properties to automatically splice the applications. See Configure the HTTP session manager with WAS for more information about splicing the application.
- If you are using a remote scenario where container servers run in different processes than the servlets, set the timeout.resume.session custom property in the WebSphere Application Server administrative console. By default, WebSphere Portal verifies the HTTP session ID at various times during a request. When you are running a WebSphere eXtreme Scale remote scenario and the number of HTTP sessions is higher than the configured sessionTableSize parameter, the session ID can change. For more information about the sessionTableSize attribute, see Servlet context initialization parameters. You must configure the timeout.resume.session custom property within the WP_ConfigService resource environment provider to prevent users from needing to log in again after the session times out.
- In the WebSphere Application Server administrative console, click Resources > Resource Environment > Resource Environment Providers > WP_ConfigService > Custom Properites > New.
- Create a custom property with a name of timeout.resume.session and a value of true.
- If you are using the remote scenario, where the 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
For more information about starting container servers, see Start container processes. If you are using an embedded scenario, see Configure container servers in WAS for more information about configuring and starting container servers.
- Restart the WebSphere Portal servers. See WebSphere Portal v7: Starting and stopping servers, deployment managers, and node agents for more information.
ResultsYou can access the WebSphere Portal Server, and HTTP session data for the configured custom portlets is persisted to the data grid.
Parent topic:Configure HTTP session managers
Configure the HTTP session manager with WAS
Configure the HTTP session manager for various application servers
XML files for HTTP session manager configuration
Servlet context initialization parameters
WebSphere Portal v7.0: Configuring user session persistance