Replication

 

+

Search Tips   |   Advanced Search

 

The data replication service (DRS) transfers data for session manager, dynamic cache, and stateful session beans across multiple appservers in a cluster.

Session manager uses DRS when configured to do memory-to-memory replication.

Dynamic cache uses DRS to copy cache information across appservers in the cluster, preventing the need to repeatedly perform the same tasks and queries in different appservers.

Stateful session beans use the replication service so that applications using stateful session beans are not limited by unexpected server failures.

You can define the number of replicas that DRS creates on remote appservers. A replica is a copy of the data that copies from one appserver to another. The number of replicas that you configure affects the performance of the configuration. Smaller numbers of replicas result in better performance because the data does not have to copy many times. However, if you create more replicas, you have more redundancy in your system. By configuring more replicas, your system becomes more tolerant to possible failures of appservers in the system because the data is backed up in several locations.

By having a single replica configuration defined, you can avoid a single point of failure in the system. However, if your system must be tolerant to more failure, introduce extra redundancy in the system. Increase the number of replicas that you create for any HTTP session that is replicated with DRS.

Any replication domain that is used by dynamic cache must use a full group replica.

Session manager, dynamic cache, and stateful session beans are the three consumers of replication. The same types of consumers belong to the same replication domain.

For example, if you are configuring both session manager and dynamic cache to use DRS to replicate objects, create separate replication domains for each consumer. Create one replication domain for all the session managers on all the appservers and one replication domain for the dynamic cache on all the appservers. The only exception to this rule is to create one replication domain if you are configuring replication for HTTP sessions and stateful session beans. Configuring one replication domain in this case ensures that the backup state information is located on the same backup appservers.


 

Related concepts

Stateful session bean failover for the EJB container
Memory-to-memory replication

 

Related tasks

Configure cache replication
Replicating data across appservers in a cluster