10.6 General properties for session management
The session management settings allow the administrator to tune a number of parameters that are important for both local or persistent sessions.
- Maximum in-memory session count
Maximum number of sessions to maintain in memory. The meaning differs depending on whether you are using local or persistent sessions. For local sessions, this value specifies the number of sessions in the base session table. Select Allow overflow to specify whether to limit sessions to this number for the entire session manager, or to allow additional sessions to be stored in secondary tables.
For persistent sessions, this value specifies the size of the general cache. This value determines how many sessions will be cached before the session manager reverts to reading a session from the database automatically. Session manager uses a least recently used (LRU) algorithm to maintain the sessions in the cache.
This value holds when you use local sessions, persistent sessions with caching, or persistent sessions with manual updates. The manual update cache keeps the last n time stamps representing the last access times, where n is the maximum in-memory session count value.
- Allow overflow
Choosing this option specifies whether to allow the number of sessions in memory to exceed the value specified in the maximum in-memory session count field. If Allow overflow is not checked, then WebSphere limits the number of sessions held in memory to this value.
For local sessions, if this maximum is exceeded and Allow overflow is not checked, then sessions created thereafter will be dummy sessions and will not be stored in the session manager.
The IBM HttpSession extension can be used to react if sessions exceed the maximum number of sessions specified when overflow is disabled.
com.ibm.websphere.servlet.session.IBMSession sess = (com.ibm.websphere.servlet.session.IBMSession) req.getSession(true); if(sess.isOverFlow()) { // Direct to a error page... }Allowing an unlimited amount of sessions can potentially exhaust system memory and even allow for system sabotage. Someone could write a malicious program that continually hits your site, creating sessions, but ignoring any cookies or encoded URLs and never utilizing the same session from one HTTP request to the next.
- Session timeout
If you select Set timeout, when a session is not accessed for this many minutes it can be removed from the in-memory cache and, if persistent sessions are used, from the persistent store. This is important for performance tuning. It directly influences the amount of memory consumed by the JVM in order to cache the session information.
For performance reasons, the session manager invalidation process runs at regular intervals to invalidate any invalid sessions. This interval is determined internally based on the Session timeout interval specified in the Session manager properties. For the default timeout value of 30 minutes, the invalidation process interval is around 300 seconds. In this case, it could take up to 5 minutes (300 seconds) beyond the timeout threshold of 30 minutes for a particular session to become invalidated.
The value of this setting is used as a default when the session timeout is not specified in a Web module's deployment descriptor.
If you select No timeout, a session will be never removed from the memory unless explicit invalidation has been performed by the servlet. This can cause a memory leak when the user closes the window without logging out from the system. This option might be useful when sessions should be kept for a while until explicit invalidation has been done, when an employee leaves the company, for example. To use this option, make sure that enough memory or space in a persistent store is kept to accommodate all sessions.
- Security integration
When security integration is enabled, the session manager associates the identity of users with their HTTP sessions.
Do not enable this property if the appserver contains a Web application that has form-based login configured as the authentication method and the local operating system is the authentication mechanism. It will cause authorization failures when users try to use the Web application.
- Serialize session access
In WebSphere V4, sessions could be accessed concurrently, meaning multiple threads could access the same session at the same time. It was the programmer's responsibility to serialize access to the session to avoid inconsistencies.
In WebSphere V5 and WebSphere V6, this option is available to provide serialized access to the session in a given JVM. This ensures thread-safe access when the session is accessed by multiple threads. No special code is necessary for using this option. This option is not recommended when framesets are used heavily because it can affect performance.
An optional property, Maximum wait time, can be set to specify the maximum amount of time a servlet request waits on an HTTP session before continuing execution. The default is two minutes.
If you set the Allow access on timeout option, multiple servlet requests that have timed out concurrently will execute normally. If it is false, servlet execution aborts.