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 in the following situations:
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 that are allowed in memory at any given time.
Configure session persistence using one of the following methods:
Database persistence, supported for the web container only
Memory-to-memory session state replication using the data replication service available in distributed server environments
All information that is stored in a persistent session store must be serialized. As a result, all of the objects that are 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 that are held by a session serialized, even if immediate plans do not call for the use of persistent session management. If the website grows and if persistent session management becomes necessary, the transition between local and persistent management occurs transparently to the application if the sessions hold only serialized objects. If the sessions do not hold serialized object, 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.
Memory-to-memory replication uses the data replication service to replicate data across many application servers in a cluster without using a database. Using this method, sessions are stored in the memory of an application server, providing the same functionality as a database for session persistence. Separate threads handle this functionality within an existing application server process.
The data replication service is an internal WebSphere Application Server component. In addition to its use by the session manager, it is also used to replicate dynamic cache data and stateful session beans across many application servers in a cluster. Using memory-to-memory replication eliminates the impact and cost of setting up and maintaining a real-time production database. It also eliminates the single point of failure that can occur with a database. Session information between application servers is encrypted.
Data replication service modes
The memory-to-memory replication function is accomplished by the creation of a data replication service instance in an application server that communicates to other data replication service instances in remote application servers.
You can set up a replication service instance to run in any of the following modes:
In this mode, a server stores only backup copies of other application server sessions. It does not send copies of sessions that are created in that particular server.
In this mode, a server broadcasts or sends only copies of the sessions it owns. It does not receive backup copies of sessions from other servers.
In this mode, the server simultaneously sends copies of the sessions it owns and acts as a backup table for sessions that are owned by other application servers.
You can select the replication mode of server, client, or both when configuring the session management facility for memory-to-memory replication. The default is both modes.
With respect to mode, these are the primary examples of memory-to-memory replication configuration:
Although the administrative console allows flexibility and additional possibilities for memory-to-memory replication configuration, only these configurations are officially supported.
There is a single replica in a cluster by default. You can modify the number of replicas through the replication domain.
The memory-to-memory replication function is accomplished by the creation of a data replication service instance in an application server that communicates to other data replication service instances in remote application servers. You must configure this data replication service instance as a part of a replication domain.
Data replication service instances on disparate application servers that replicate to one another must be configured as a part of the same domain. You must configure all session managers connected to a replication domain to have the same topology. If one session manager instance in a domain is configured to use the client/server topology, then the remainder of the session manager instances in that domain must be a combination of servers that are configured as client only and server only.
If one session manager instance is configured to use the peer-to-peer topology, then all session manager instances must be configured as both client and server. For example, a server-only data replication service instance and a both client and server data replication service instance cannot exist in the same replication domain. Multiple data replication service instances that exist on the same application server due to session manager memory-to-memory configuration at various levels that are configured to be part of the same domain must have the same mode.
Create a separate replication domain for each consumer. For example, create one replication domain for session manager and another replication domain for dynamic cache. Configure one replication domain only when you configure session manager replication and stateful session bean failover. Using one replication domain in this situation ensures that the backup state information of HTTP sessions and stateful session beans are on the same application server.
Replication domain configuring
A single replica allows you to replicate a session to only one other server, which is the default. When you choose this option, a session manager picks another session manager that is connected to the same replication domain with which to replicate the HTTP session during session creation. All updates to the session are replicated to that single server. This option is set at the replication domain level.
When this option is set, every session manager that is connected to this replication domain creates a single backup copy of the HTTP session state information about a backup server.
Alternatively, you can replicate to every application server that is configured as a consumer of the replication domain using the "Entire Domain" option, or you can replicate to a specified number of replicas within the domain.