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:

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.

Procedure

  1. Splice the wps WebSphere Portal application and any custom portlets to enable the sessions to be stored in the 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 Configuración del gestor de sesiones HTTP con WebSphere Application Server for more information about splicing the application.

  2. 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
    For more information about starting container servers, see Inicio de servidores de contenedor. If you are using an embedded scenario, see Configuración de servidores de contenedor en WebSphere Application Server for more information about configuring and starting container servers.
  3. 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.