Cleanup

When a session spends a given amount of time without processing any request, the session times out. When this occurs, the data associated with the session, both toolkit internal data and application data, remains stored in memory. The application must clean up the session resources.

The session management provided by the toolkit can use cookies or not use cookies. This is controlled by the following setting in the toolkit configuration (btt.xml) file:

If the cookies field is set to true, WebSphere Application Server performs session management. When the toolkit establishes a session, it creates an HTTPSession object. This causes WebSphere to become aware of the session, and the application can then use WebSphere's session capabilities. The toolkit delegates to WebSphere the detection of session expiration. If the cookies field is set to false, the toolkit performs session management internally.

The toolkit lets the application decide what to store in a session and how to store it. The toolkit only requires that the session have an entry in the session table and a context. Once the session has been established, the application executes an operation to add the session entry to the sessions table.

While the toolkit does not provide a session startup operation, the sample applications provide examples of ways to implement one according to the concrete channel implementation being used. The operation establishes the session by placing an entry in the session table and by creating a context for the session. Once this occurs, the toolkit is aware of the session. The following diagram shows a context and its entry in the session table:

The session context and the session entry can store any application information and the session context can initiate services. The application must be aware of this data and any running services when handling the expiry of the session.

When a session spends a given amount of time without processing any request, the session times out. When this occurs, the application must clean up the resources allocated for this session as part of the session expiry. See Managing session for information on how to configure and handle application sessions.

An application subsession is a session within a session. The application subsession also has a context. The toolkit automatically chains this context to the session context so each request running in the application subsession has access to the application subsession context and the session context. An application shares the same session context with the rest of the applications running under this session but each of them has its own application context.

The application subsession context stores only the following three toolkit internal fields:

The dse_sessionId is the application session ID. The other two parameters are for HTML processor management because memory usage related to HTML processors is associated with an application subsession instead of the session.

The application subsession has a freely accessible context for the application to retain any information and service definitions. The application should clean up all of this information when the subapplication session is no longer available. This cleanup can occur as part of the application subsession expiry or as part of a specific application session cleanup occurring during session expiration.

Note that application subsessions are always associated with only one session. When an application session expires, it is the responsibility of the application to perform any needed cleanup for the session and all the application subsessions associated with it. Once an application session has expired, the toolkit treats all its application subsessions as expired also, and no longer checks the application subsessions for timeout. This can cause a problem if an application session expires and the application does not clean up its subsessions, because it means that the application will never be notified of the expiration of those subsessions.