![[Note]](images.admon/note.gif) | |
|
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:
Application
Application server
Web module
When you are planning for session data, keep in mind the following basic considerations:
Application design
Session storage options
Session tracking mechanism
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.
Cookies
Using cookies as a session tracking mechanism is common. WebSphere session management generates a unique session ID and returns it to the user's web browser to be stored as a cookie.
URL rewriting
URL rewriting requires the developer to use special encoding APIs, and to set up the site page flow to avoid losing the encoded information. The session identifier is stored in the page returned to the user. WebSphere encodes the session identifier as a parameter on URLs that are encoded programmatically by the web application developer.
URL rewriting can be used only for pages that are dynamically generated for each request, such as pages generated by servlets or JSPs. If a static page is used in the session flow, the session information is lost. URL rewriting forces the site designer to plan the user's flow in the site to avoid losing their session ID.
SSL ID tracking
With SSL ID tracking, SSL session information is used to track the session ID. Because the SSL session ID is negotiated between the web browser and an HTTP server, it cannot survive an HTTP server failure. However, the failure of an application server does not affect the SSL session ID. In environments that use WebSphere components with multiple HTTP servers, use an affinity mechanism for the web servers when SSL session ID is used as the session tracking mechanism.
When the SSL session ID is used as the session tracking mechanism in a clustered environment, use either cookies or URL rewriting to maintain session affinity. The cookie or rewritten URL contains session affinity information. This information enables the web server to properly route requests back to the same server after the HTTP session is created on a server. The SSL ID is not sent in the cookie or a rewritten URL. Rather, it is derived from the SSL information.
The disadvantage of using SSL ID tracking is the performance degradation because of the SSL resource requirements.
Selecting multiple tracking mechanisms
You can combine multiple options for a web application:
Use of SSL session identifiers has a preference to cookie and URL rewriting.
Use of cookies has a preference to URL rewriting.
If you select SSL session ID tracking, consider also selecting cookies or URL rewriting to maintaining session affinity. The cookie or rewritten URL contains session affinity information. This information enables the web server to properly route a session back to the same server for each request.
Storage of session-related information
You can choose to store the session data by using one of these options:
Local sessions (non-persistent)
Database persistent sessions
Memory-to-memory replicated persistent sessions
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.
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 local session storage:
Maximum in-memory session count
With this setting, you can define a limit to the number of sessions in memory. This setting prevents the sessions from acquiring too much of the JVM heap and causing out-of-memory errors.
Allow overflow
This setting allows an unlimited number of sessions. If you choose this option, monitor the session cache size closely.
Tip: Session overflow is enabled by default in WebSphere Application Server V8.5.
Session timeout
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 Application Server 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 Application Server session manager breaks the session data across multiple rows if the size of the session object exceeds the size for a row. This setting 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 replications enable the sharing of sessions between application servers. Using memory-to-memory replication eliminates the effort of maintaining a production database and eliminates the SPOF that can occur with a database. You can choose the number of replicas and the level of persistence. Depending on this configuration, replicating the session impacts the performance. The service transfers copies of objects across the network, and these new objects reduce the memory heap that is available for the other objects.
Memory-to-memory replication is based on the generic DRS.
Availability: Memory-to-memory persistence is available only in a distributed server environment by using WebSphere Application Server Network Deployment.
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:
To one server (single replica)
You can replicate a session to only one other server, creating a single replica. When this option is chosen, a session manager picks another session manager that is connected to the same replication domain to replicate the HTTP session to during session creation. All updates to the session are only replicated to that single server. This option is set at the replication domain level. When this option is set, every session manager connected to this replication domain creates a single backup copy of HTTP session state information on a backup server.
To every server (entire domain)
Each object is replicated to every application server that is configured as a consumer of the replication domain. However, in the peer-to-peer mode, this topology is the most redundant because all servers replicate to each other, and as you add servers, more processors and memory are needed to manage replication. Entire domain is most useful for dynamic caching replication. Redundancy does not affect the client/server mode because clients replicate only to servers that are set to server mode.
Attention: Do not use entire domain in a large topology, as the infrastructure cannot handle the large number of connections that are necessary to support this configuration.
To a defined set of servers
You can specify a specific number of replicas for any entry that is created in the replication domain. The number of replicas is the number of application servers that you want to replicate in the domain. This option eliminates redundancy that occurs in a full group replica, and also provides additional backup over a single replica. In peer-to-peer mode, the number of replicas cannot exceed the total number of application servers in the cluster. In the client/server mode, the number of replicas cannot exceed the total number of application servers in the cluster that are set to server mode.
On multiple application server nodes, the number of replicas must match the number of application servers on a node to ensure that a backup exists on a different node. For example, if you have two nodes with three application servers on each node, you would want to set the number of replicas to three. Location of backups is randomly selected and in a worse case scenario, the application server backups might be selected on the same node. Setting number of replicas to three ensures that at least one backup exists on a different node.
When you add an application server to a replication domain, you must specify the replication mode for the server:
Server mode
In this mode, a server stores only backup copies of other application server data. It does not send copies of its own data to other application servers.
Client mode
In this mode, a server broadcasts or sends only copies of its own data. It does not receive copies of sessions from other servers.
Both mode
In this mode, the server can send its own data and receive data from other application servers. Because each server has a copy of all of the data, this mode uses the most memory on each 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.
