Memory-to-memory replication
The new feature of memory-to-memory replication enables the sharing of sessions between appservers without using a database. There are two ways this function can be configured: client-server or peer-peer. In our example we are going to use peer-peer (which is also the default) to depict how session failover works.
For an in-depth explanation of this function, consult Chapter 14, "Configuring session management" of the redbook IBM WebSphere Version 5.0 System Management and Configuration, SG24-6195.
The benefits of using in-memory replication rather than a database for session persistence is that the overhead and cost of setting up and maintaining a real-time, production database, such as preparing a machine, installing and configuring a database, starting and so on, is not needed. Also, the database becomes a SPOF (Single Point Of Failure) for session persistence and certain cost and effort is required to solve this issue at the database level. However, it was found that database persistence normally performs better than memory-to-memory replication. See HTTP sessions and the session management facility for additional information.
All features available in database persistence are available in memory-to-memory replication as well, except for DB2 variable row size and multi-row features, which are features specific to a database.
To effectively deploy memory-to-memory replication in clustered environments, especially large ones, implementers must think carefully how to exactly configure the replicator topology and settings. If care isn't taken then the amount of memory and resource usage taken by session replication can increase significantly.
The following is a high-level description of how to set up this function. Refer to 7.5, Configuring WebSphere clusters or, again, to Chapter 14 of the redbook IBM WebSphere Version 5.0 System Management and Configuration, SG24-6195 for details on how to configure this.
Replicator domains define the set of replicator processes that communicate with each other.
Replicator entries, or simply replicators, run inside an appserver process and define its basic settings, such as a communication port among replicators and a communication port with clients.
In our example we have two cluster members in PluginCluster: PluginMember1 and PluginMember2. If we make an initial session-based request to PluginMember1 and shut it down afterwards, the plug-in will then try and route requests through to PluginMember2. In general, if the plug-in is unable to contact the initial server it will try another cluster member. The next cluster member that responds will already have the session in memory since it has been replicated using memory-to-memory replication.
Again, when the servlet returns the result to the plug-in, the cluster member that served the page is appended to the list of clone IDs in the session identifier. The session identifiers now look like those shown in Example 5-11.
Example 5-11 Example of session JSESSION cookies with multiple clone IDs
JSESSIONID=0002YBY-wJPydXZvCZkc-LkoBBH:v544d031:v544d0o0
The plug-in now tries both of these servers before resorting to the workload management algorithm again. Once the original server is available again, all session requests will return to it.
If you wish to test whether the failover and persistent sessions are working, follow the steps in 5.7, Web server plug-in behavior and failover.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.