Session Support for Concurrent Requests 

Use

The Web Container provides a special, configurable function, to prevent HTTP session loss in case concurrent requests to a remote server are issued from the same client. A typical example is a portal page that contains two iViews that point to Web components residing on remote server processes (within different Java instance in the same SAP system, or within different SAP systems). In this case, each of the concurrent requests can be dispatched to different Java server processes by the Java dispatcher as they do not belong to any HTTP sessions on the server. As a result, each of the requests gets different load balancing and session cookies with the response. However, the browser accepts only the last cookies received, which leads to session loss for one of the consequent requests.

This function is only relevant if both remote systems share the same JSESSIONID.

Features

To address this issue, you can use a temporary session table that is implemented on the Java dispatcher. If this table is enabled, it stores the JSESSIONID that is mapped to the concrete server ID for all requests that either do not have a load balancing cookie set, or the cookie is not valid. The entries are stored for a certain timeout period, which is configured with a property of the HTTP Provider service. The timeout is calculated based on the session’s inactivity period. That is, if no request with the same JSESSIONID is received within the specified timeout period, the corresponding entry expires.

As a consequence, for a certain period of time, all requests with the same JSESSIONID (available in the temporary table) are dispatched to the same server process (identified by the server ID mapped to the JSESSIONID).

The temporary session table function transparently provides a degree of session failover, as it guarantees that consequent requests with the same JSESSIONID is dispatched to the same server process.

Activities

To enable the temporary session table function, you need to set the timeout period for its entries using the SessionTableTimeout property of the HTTP Provider service on the dispatcher. By default, this table is not used.

When setting the timeout period for the entries of the temporary session table, consider carefully the average round-about time of the concurrent requests. Setting a timeout that is too short practically invalidates the use of the session table, as the entries in it are invalidated before the next requests are sent. Setting a timeout period that is too high can increase memory usage.

For more information about possible values of the SessionTableTimeout property, see HTTP Provider Service.