In-memory replication on other servers provides lightweight storage of session state data without the need to obtain a separate database, such as HADB. This type of replication uses memory on other servers for high availability storage of HTTP session and stateful session bean data. Clustered server instances replicate session state in a ring topology. Each backup instance stores the replicated data in memory. Replication of session state data in memory on other servers enables sessions to be distributed.
The use of in-memory replication requires the Group Management Service (GMS) to be enabled. For more information about GMS, see Group Management Service.
If server instances in a cluster are located on different machines, ensure that the following prerequisites are met:
To ensure that GMS and in-memory replication function correctly, the machines must be on the same subnet.
To ensure that in-memory replication functions correctly, the system clocks on all machines in the cluster must be synchronized as closely as possible.
Considerations for using in-memory replication:
Very simple to set up and use. There are little or no administration costs.
More Java Virtual Machine (JVM) heap space is used. JVM will need tuning for any production system.
Does NOT provide 99.999% availability. Therefore, in-memory replication is unsuitable for any customer that requires this level of availability.
Typically incurs less overhead than HADB does.
Cannot be used to create a highly available Message Queue cluster. This is only possible by using a highly available database.
Although an Application Server does cluster its Message Queue instances, this provides only a conventional Message Queue cluster and not a highly available Message Queue cluster.
For information on Message Queue requirements, see Sun Java System Message Queue 4.1 Administration Guide.