Memory-to-memory replication
Memory-to-memory session replication is the session replication to another WebSphere Application Server. In this mode, sessions can replicate to one or more Application Servers to address HTTP Session single point of failure (SPOF).
The WAS instance in which the session is currently processed is referred to as the owner of the session. In a clustered environment, session affinity in the WAS plug-in routes the requests for a given session to the same server. If the current owner server instance of the session fails, then the WAS plug-in routes the requests to another appropriate server in the cluster. In a peer-to-peer cluster, the hot failover feature causes the plug-in to failover to a server that already contains the backup copy of the session, avoiding the overhead of session retrieval from another server containing the backup. In a client/server cluster, the server retrieves the session from a server that has the backup copy of the session. The server now becomes the owner of the session and affinity is now maintained to this server.
(iSeries) The WAS profile in which the session is currently processed is referred to as the owner of the session. In a clustered environment, session affinity in the WAS plug-in routes the requests for a given session to the same server. If the current owner server profile of the session fails, then the WAS plug-in routes the requests to another appropriate server in the cluster. In a peer-to-peer cluster, the hot failover feature causes the plug-in to failover to a server that already contains the backup copy of the session, avoiding the overhead of session retrieval from another server containing the backup. In a client/server cluster, the server retrieves the session from a server that has the backup copy of the session. The server now becomes the owner of the session and affinity is now maintained to this server.
There are three possible modes to run in:
Server mode Only store backup copies of other WAS sessions. Do not to send out copies of any session created in that particular server Client mode Only broadcast or send out copies of the sessions it owns. Do not receive backup copies of sessions from other servers Both mode Simultaneously broadcast or send out copies of the sessions it owns and act as a backup table for sessions owned by other WAS instances. (iSeries) Both mode Simultaneously broadcast or send out copies of the sessions it owns and act as a backup table for sessions owned by other WAS profiles. We 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. This storage option is controlled by the mode parameter.
The memory-to-memory replication function is accomplished by the creation of a data replication service instance in an application server that talks to other data replication service instances in remote application servers. 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. 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 rest of the session manager instances in that domain must be a combination of servers 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 configured to be part of the same domain must have the same mode.
With respect to mode, the following 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 the configurations provided are officially supported.
There is a single replica in a cluster by default. We can modify the number of replicas through the replication domain.
(ZOS) HTTP session replication in the controller
WASs on z/OS enabled for HTTP session memory-to-memory replication can store replicated HTTP session data in the controller and replicate data to other WASs. HTTP session data stored in a controller is retrievable by any of the servants of that controller. HTTP session affinity is still associated to a particular servant; however, if that servant should fail, any of the other servants can retrieve the HTTP session data stored in the controller and establish a new affinity.
The capability of storing HTTP sessions in the controller can also be enabled in unmanaged application servers on z/OS. When this capability is enabled, servants store the HTTP session data in the controller for retrieval when a servant fails which is similar to managed servers. HTTP session data stored in the controller of an unmanaged application server is not retrievable by other application servers and is not replicated to other application servers.
The capability to store HTTP session data in the controller in an unmanaged application server is enabled by setting the JVM custom property HttpSessionEnableUnmanagedServerReplication to true. We can set this property at...
Servers > Application servers > server > Server Infrastructure > Java and Process Management > Process Definition > Servant > Java Virtual Machine > Custom Properties
Subtopics
Related:
Data replication Replicating data with a multi-broker replication domain