Session management implementation

For all devices, the toolkit provides an implementation that can be used by an application if the channel does not provide for session management or the particular application does not require session management. For example, if the browser does not have cookies enabled and you are using the HTTP communication protocol, neither the HttpSession nor the servlet engine session management can be used. To cover this scenario, the toolkit provides the following optional parameters in the CSServer element tag:

▪ inactivityClientIdle, which specifies the timeout threshold value to monitor when the session is idle for a specified duration (in milliseconds)

▪ timeBetweenSessionCheck, which is the time that the thread that checks for expired sessions will sleep from one check to the next (in milliseconds)

These parameters allow the multichannel support implementation, and in particular the Client/Server Service (CSServer), to use the application session table to manage sessions. If the parameter does not exist in the CSServer element tag, or the cookies parameter in btt.xml is set to true, the multichannel support implementation will not manage the inactivity timeout, since it will be managed by the specific channel session manager implementation.

The following entry in the toolkit services definition file on the server (dsesrvc.xml) specifies that the session will time out after 10 seconds (10,000 milliseconds) and the thread that looks for expired sessions will awake every two minutes (120,000 milliseconds):

To provide a way of cleaning up the resources allocated by an application subsession independent of the expiration of its parent session, the CSServer tag also has the appSessionTimeout attribute. This optional attribute defines how long an application subsession remains without processing any request before the CSServer service fires the CSInactivityClientEvent timeout. The following is an example:

The Client/Server Service fires a CSInactivityClientEvent to notify the registered listeners that a session has expired, and it is the responsibility of the application implementation to remove the session entries from the application session entry table and perform any other cleanup of the sessions. To specify whether the expiring session is the main session or an application subsession, the toolkit sets the appSessionId attribute of the event, either to the ID of the expiring application subsession or to null if the main (channel) session is expiring. The application must check the value of this attribute to determine whether it must perform a session or application subsession housekeeping process.

If a valid inactivity timeout is specified for the Client/Server Service and the timestamp of the application session is null, the toolkit does not signal an event. Instead, it is expected that the event will be raised by the channel implementation of session management.

The application session entry information is maintained in local memory and is not persisted, unless session persistence is enabled (see Persistence schema for load-balancing and failover support). The application session entry table is maintained by the Context class as a keyed collection of the following elements, which are listed in the application session table for each session:

The timestamp of the last time that the session table was accessed. This is required for the toolkit implementation of the session management (No channel session management). Null if the channel driver provides the session management.. In this case, no event will be raised as a result of session inactivity.

Flag indicating if this session has expired. If it has expired, no more requests will be allowed to run under this session. It is the responsibility of the application to remove the expired session from the table.