10.5 Local sessions
Many Web applications use the simplest form of session management: the in-memory, local session cache. The local session cache keeps session information in memory and local to the machine and WAS where the session information was first created.
Local session management does not share user session information with other clustered machines. Users only obtain their session information if they return to the machine and WAS holds their session information about subsequent accesses to the Web site.
Most importantly, local session management lacks a persistent store for the sessions it manages. A server failure takes down not only the WebSphere instances running on the server, but also destroys any sessions managed by those instances.
WebSphere allows the administrator to define a limit on the number of sessions held in the in-memory cache from the console settings on the session manager. This prevents the sessions from acquiring too much memory in the Java VM associated with the appserver.
The session manager also allows the administrator to permit an unlimited number of sessions in memory. If the administrator enables the Allow overflow setting on the session manager, the session manager permits two in-memory caches for session objects. The first cache contains only enough entries to accommodate the session limit defined to the session manager, 1000 by default. The second cache, known as the overflow cache, holds any sessions the first cache cannot accommodate, and is limited in size only by available memory. The session manager builds the first cache for optimized retrieval, while a regular, un-optimized hash table contains the overflow cache.
For best performance, define a primary cache of sufficient size to hold the normal working set of sessions for a given Web appserver.
If you enable overflow, the session manager permits an unlimited number of sessions in memory. Without limits, the session caches might consume all available memory in the WebSphere instance's heap, leaving no room to execute Web applications. For example, two scenarios under which this could occur are:
- The site receives greater traffic than anticipated, generating a large number of sessions held in memory.
- A malicious attack occurs against the site where a user deliberately manipulates their browser so the application creates a new session repeatedly for the same user.
If you choose to enable session overflow, the state of the session cache should be monitored closely.
Each Web application will have its own base, or primary, in-memory session cache, and with overflow allowed, its own overflow, or secondary, in-memory session cache.