5.3.  Configure session management (memory-to-memory, database persistence).

[Note]

Session support

Information entered by a user in a Web application is often needed throughout the application. For example, a user selection might be used to determine the path through future menus or options to display content. This information is kept in a session.

A session is a series of requests to a servlet that originate from the same user. Each request arriving at the servlet contains a session ID. Each ID allows the servlet to associate the request with a specific user. 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.

When planning for session data, there are three basic considerations:

Application design

Although using session information is a convenient method for the developer, this usage should be minimized. Only objects really needed for processing of subsequent requests should be stored in the session. If sessions are persisted during runtime, there is a performance impact if the session data is too big.

Session tracking mechanism

You can choose to use cookies, URL rewriting, SSL session IDs, or a combination of these as the mechanism for managing session IDs.

It is possible to combine multiple options for a Web application.

If selecting SSL session ID tracking, we suggest that you also select cookies or URL rewriting so that session affinity can be maintained. The cookie or rewritten URL contains session affinity information enabling the Web server to properly route a session back to the same server for each request.

Storage of session-related information

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

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.

Storing session data external to the system can have drawbacks in performance. The amount of impact depends on the amount of session data, the method chosen, and the performance and capacity of the external storage. Session management implements caching optimizations to minimize the impact of accessing the external storage, especially when consecutive requests are routed to the same application server.

Local sessions (non-persistent)

If the session data is stored in the application server memory only, 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:

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.

The Use multi-row schema setting gives you the option to use multi-row sessions to support large session objects. With multi-row support, the WebSphere session manager breaks the session data across multiple rows if the size of the session object exceeds the size for a row. This also provides a more efficient mechanism for storing and retrieving session contents when session attributes are large and few changes are required to the session attributes.

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:

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:

Session manager settings

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

The following session management properties can be set:

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.

WebSphere assures that session affinity is maintained in the following way: Each server ID is appended to the session ID. When an HTTP session is created, its ID is passed back to the browser as part of a cookie or URL encoding. When the browser makes further requests, the cookie or URL encoding will be sent back to the Web server. The Web server plug-in examines the HTTP session ID in the cookie or URL encoding, extracts the unique ID of the cluster member handling the session, and forwards the request.

This situation can be seen in figure below, where the session ID from the HTTP header, request.getHeader("Cookie"), is displayed along with the session ID from session.getId(). The application server ID is appended to the session ID from the HTTP header. The first four characters of HTTP header session ID are the cache identifier that determines the validity of cache entries.

Figure 5.6. Session ID containing the server ID and cache ID

Session ID containing the server ID and cache ID


The JSESSIONID cookie can be divided into these parts: cache ID, session ID, separator, clone ID, and partition ID. JSESSION ID will include a partition ID instead of a clone ID when memory-to-memory replication in peer-to-peer mode is selected. Typically, the partition ID is a long numeric number.

Table below shows their mappings based on the previous example. A clone ID is an ID of a cluster member.

Table 5.1.  Cookie mapping

ContentValue in the example

Cache ID

0000

Session ID

SHOQmBQ8EokAQtzl_HYdxIt

Separator

:

Clone ID

vuel491u


The application server ID can be seen in the Web server plug-in configuration file, plug-in-cfg.xml file, as shown in the example below:


<?xml version="1.0" encoding="ISO-8859-1"?>
<Config>
    ......
    <ServerCluster Name="MyCluster">
        <Server CloneID="vuel491u" LoadBalanceWeight="2" Name="NodeA_server1">
            <Transport Hostname="wan" Port="9080" Protocol="http"/>
            <Transport Hostname="wan" Port="9443" Protocol="https">
    ......
</Config>
					
					

Note: Session affinity can still be broken if the cluster member handling the request fails. To avoid losing session data, use persistent session management. In persistent sessions mode, cache ID and server ID will change in the cookie when there is a failover or when the session is read from the persistent store, so do not rely on the value of the session cookie remaining the same for a given session.

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.

Figure 5.7. Session affinity and failover

Session affinity and failover


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.

The Web server plug-in maintains a cluster member list and picks the cluster member next in the list to avoid the breaking of session affinity. From then on, requests for that session go to the selected cluster member. The requests for the session go back to the failed cluster member when the failed cluster member restarts.

WebSphere provides session affinity on a best-effort basis. There are narrow windows where session affinity fails. These windows are as follows:

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:

There are two ways to configure session persistence as shown below:

All information stored in a persistent session store must be serialized. As a result, all of the objects held by a session must implement java.io.Serializable if the session needs to be stored in a persistent session store.

In general, consider making all objects held by a session serialized, even if immediate plans do not call for the use of persistent session management. If the website grows, and persistent session management becomes necessary, the transition between local and persistent management occurs transparently to the application if the sessions only hold serialized objects. If not, a switch to persistent session management requires coding changes to make the session contents serialized.

Persistent session management does not impact the session API, and Web applications require no API changes to support persistent session management. However, as mentioned previously, applications storing unserializable objects in their sessions require modification before switching to persistent session management.

If you use database persistence, using multi-row sessions becomes important if the size of the session object exceeds the size for a row, as permitted by the WebSphere session manager. If the administrator requests multi-row session support, the WebSphere session manager breaks the session data across multiple rows as needed. This allows WebSphere to support large session objects. Also, this provides a more efficient mechanism for storing and retrieving session contents under certain circumstances.

Using a cache lets the session manager maintain a cache of most recently used sessions in memory. Retrieving a user session from the cache eliminates a more expensive retrieval from the persistent store. The session manager uses a "least recently used" scheme for removing objects from the cache. Session data is stored to the persistent store based on your selections for write frequency and write option.

Professional hosting         Free 'Oracle Certified Expert Web Services Developer 6' Guide     Free SCDJWS 5.0 Guide