Session Management in WAS

A Session is a series of requests to a servlet, originating from the same user at the same browser.  The WebSphere session management component is responsible for managing sessions, providing storage for session data, allocating session IDs that identify a specific session, and tracking the session ID associated with each client request through the use of cookies or URL rewriting techniques.

Session Management:

You can choose whether to store the session data as follows:

• Local sessions (non-persistent)
• Database persistent sessions
• Memory-to-memory replicated persistent sessions

 The last two options allow session data to be accessed by multiple servers and should be considered when planning for failover. Using a database or session replication is also called session persistence.

Local sessions (non-persistent)

If the session data is stored in the application server memory only(Heap Memory), the session data is not available to any other servers. Although this option is the fastest and the simplest to set up, an application server failure ends the session, because the session data is lost.

The following settings can help you manage the local session storage:

Maximum in-memory session count: This setting enables you to define a limit to the number of sessions in memory. This prevents the sessions from acquiring too much of the JVM heap and causing out-of-memory errors.

Allow overflow: This setting permits an unlimited number of sessions. If you choose this option, monitor the session cache size closely.

Session time-out:This setting determines when sessions can be removed from cache.

Database persistent sessions

You can store session data in an external database. The administrator must create the database and configure the session database in WebSphere through a data source.

Memory-to-memory replicated persistent sessions:

 Memory-to-memory replication copies session data across application servers in a cluster, storing the data in the memory of an application server and providing session persistence. Using memory-to-memory replication eliminates the effort of maintaining a production database and eliminates the single point of failure that can occur with a database. Test to determine which persistence mechanism is the best one in your environment.

The administrator sets up memory-to-memory replication by creating a replication domain and adding application servers to it. You can manage replication domains from the administrative console by navigating to "Environment > Replication domain". When defining a replication domain, you must specify whether each session is replicated in one of the following manners:

• To one server (single replica)
• To every server (entire domain)
• To a defined number of servers

The number of replicas can affect performance. Smaller numbers of replicas result in better performance because the data does not have to be copied into many servers. By configuring more replicas, your system becomes more tolerant to possible failures of application servers because the data is backed up in several locations.

When adding an application server to a replication domain, you must specify the replication mode for the server:

Server mode

In this mode, a server only stores backup copies of other application server sessions. It does not send copies of its own sessions to other application servers.

Client mode

In this mode, a server only broadcasts or sends copies of its own sessions. It does not receive copies of sessions from other servers.

Both mode

In this mode, the server is capable of sending its own sessions and receiving sessions from other application servers. Because each server has a copy of all sessions, this mode uses the most memory on each server. Replication of sessions can impact performance.

Session manager settings

Session management in WebSphere Application Server can be defined at the following levels:

Application server

This is the default level. Configuration at this level is applied to all Web modules within the server.

Navigate to "Servers > Server Types > Application servers > <server_name> > Session management > Distributed environment settings > Memory-to-memory replication".

Application

Configuration at this level is applied to all Web modules within the application.

Navigate to "Applications > Application Types > WebSphere enterprise applications > <app_name> > Session management > Distributed environment settings > Memory-to-memory replication".

Web module

Configuration at this level is applied only to that Web module.

Navigate to "Applications > Application Types > WebSphere enterprise applications > <app_name> > Manage modules > <web_module> > Session management > Distributed environment settings > Memory-to-memory replication".

   

The following session management properties can be set:

Session tracking mechanism

Session tracking mechanism lets you select from cookies, URL rewriting, and SSL ID tracking. Selecting cookies will lead you to a second configuration page containing further configuration options.

Maximum in-memory session count

Select Maximum in-memory session count and whether to allow this number to be exceeded, or overflow.

Session time-out

Session time-out specifies the amount of time to allow a session to remain idle before invalidation.

Security integration

Security integration specifies a user ID be associated with the HTTP session.

Serialize session access

Serialize session access determines if concurrent session access in a given server is allowed.

Overwrite session management

Overwrite session management, for enterprise application and Web module level only, determines whether these session management settings are used for the current module, or if the settings are used from the parent object.

Distributed environment settings

Distributed environment settings select how to persist sessions (memory-to-memory replication or a database) and set tuning properties.

Session affinity

In a clustered environment, any HTTP requests associated with an HTTP session must be routed to the same Web application in the same JVM. This ensures that all of the HTTP requests are processed with a consistent view of the user's HTTP session. The exception to this rule is when the cluster member fails or has to be shut down.

Session affinity and failover

Server clusters provide a solution for failure of an application server. Sessions created by cluster members in the server cluster share a common persistent session store. Therefore, any cluster member in the server cluster has the ability to see any user’s session saved to persistent storage.

If one of the cluster members fails, the user can continue to use session information from another cluster member in the server cluster. This is known as failover. Failover works regardless of whether the nodes reside on the same machine or several machines. Only a single cluster member can control and access a given session at a time.

After a failure, WebSphere redirects the user to another cluster member, and the user's session affinity switches to this replacement cluster member. After the initial read from the persistent store, the replacement cluster member places the user's session object in the in-memory cache, assuming that the cache has space available for additional entries.

Persistent session management

By default, WebSphere places session objects in memory. However, the administrator has the option of enabling persistent session management, which instructs WebSphere to place session objects in a persistent store. Administrators should enable persistent session management when:

The user's session data must be recovered by another cluster member after a cluster member in a cluster fails or is shut down.

The user's session data is too valuable to lose through unexpected failure at the WebSphere node.

The administrator desires better control of the session cache memory footprint. By sending cache overflow to a persistent session store, the administrator controls the number of sessions allowed in memory at any given time.


See the http://java.boot.by/ibm-377/ch05s03.html