Base in-memory session pool size
The base in-memory session pool size number depends on the session support configuration.
- With in-memory sessions, session access is optimized for up to this number of sessions.
- With distributed sessions, when sessions are stored in a database or in another WAS instance,; the pool size also specifies the cache size and the number of last access time updates saved in manual update mode.
For distributed sessions, when the session cache has reached its maximum size and a new session is requested, the Session Management facility removes the least recently used session from the cache to make room for the new one.
General memory requirements for the hardware system, and the usage characteristics of the e-business site, determines the optimum value.
Note that increasing the base in-memory session pool size can necessitate increasing the heap sizes of the Java processes for the corresponding WASs.
Overflow in non-distributed sessions
By default, the number of sessions maintained in memory is specified by base in-memory session pool size. If we do not wish to place a limit on the number of sessions maintained in memory and allow overflow, set overflow to true.
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 the site and creates sessions, but ignores any cookies or encoded URLs and never utilizes the same session from one HTTP request to the next.
When overflow is disallowed, the Session Management facility still returns a session with the method...
HttpServletRequest getSession(true)
...when the memory limit is reached, and this is an invalid session not saved.
With the WAS extension to HttpSession...
com.ibm.websphere.servlet.session.IBMSession...an isOverflow method returns true if the session is such an invalid session. An application can check this status and react accordingly.
Related concepts
Sessions
Related
Session management tuning