6.3.  Configure distributed session management for high availability and failover scenarios, including the WebSphere eXtreme Scale option.


Session support

As explained previously, information that is entered by a user in a web application is often needed throughout the application. The information that is coming from multiple requests from the same user is stored in a session. A session is a series of requests to a servlet that originate from the same user and the same browser. Each request that arrives 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, and allocating session IDs that identify a specific session. It is also responsible for tracking the session ID that is associated with each client request by using cookies or URL rewriting techniques. Replicating the sessions in memory between the cluster members or sharing them by using a database are also possible, and improve the availability of the solution. These techniques make the infrastructure more tolerant to application server failures.

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

When you are planning for session data, keep in mind the following basic considerations:

Application design

Although using session information is a convenient method for the developer, store only the objects that are needed for processing subsequent requests in the session. You need to minimize the size of the sessions. Keep in mind that most sessions are stored in memory. Managing large sessions comes with a performance impact.

Session tracking mechanism

You can choose to use cookies, URL rewriting, SSL session IDs, or a combination of these mechanisms to manage session IDs.

Storage of session-related information

You can choose to store the session data by using one of these options:

The last two options in this list support session data being accessed by multiple servers. Consider them when you are planning for failover. Using a database or session replication is also called session persistence.

Storing session data external to the system can affect performance. The impact depends on the amount of session data, the method that is 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.

Data replication service (DRS)

The DRS is an internal WebSphere Application Server component that is designed for generic data replication. Session manager, dynamic cache, and stateful session EJB can all use the replication service. DRS can increase the availability of your solution by replicating the data across a replication domain.

A replication domain is a group of servers that share data such as session data. For each domain, you must define how the data is replicated:

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

The number of replicas can affect performance. Smaller numbers of replicas result in better performance because the data does not have to be transferred and copied by the network into many servers. However, configuring more replicas makes your system more tolerant of failure because the data is backed up in several locations.

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