Notes on WebSphere Data Replication Services (DRS)

My Notes from the IBM Education Assistant  on DRS

DRS is a internal component of WebSphere that is used to move data within the app server process. Examples of this include

• HTTP Session replication 
• Dynamic Cache Replication 
• EJB state replication (New at WebSphere 6)

To insure that data and request wind up in the same place DRS coordinates with workload management. 

DRS provides services in two scenarios

• Fail over
• Ensure HTTP session and EJBs can be move to another server transparent to the user.  
• Caching 
• When a servlet or JSP has been configured to have it's output cached repeated request are handled faster. This cached output is what DRS syncs. 

DRS in V5 WebSphere requires the administrator to configure the replicators, replication domain and partition.

• Replicators
• Producer and Consumer responsible for moving data
• Data moves as JMS messages
• Replication Domain
• A set of one or more replicators
• Partition
• a group of replicators configured to communicate with each other.   

DRS is V6 WebSphere requires the administrator to only configure a Replication Domain as configuring replicators is no longer necessary and partition are masked from the user. 

• Replication Domain
• Consists of server or cluster members that have the capability of sharing HTTP Session or Caching data within the domain 
• New in V6 is the coordination with Workload Management (WLM) to coordinate which members serve as backups for other members.   
• Ideally session fail over data stateful session bean data should end up in the same place and somewhere other then where the data originated.  
• Rewritten in V6 using a IBM propitiatory mechanization  to transport data. 
• Only configuration option now is that the number of replications can be set (default is 1)

377 Question area 

• Creating a replication domain can be done at cluster creation. 
• 
• Or can be done manually

• Cache replication can be configured under Server - Container Services  - Dynamic cache Service

Best Practices 

• Create distinct domain for HTTP and EJB data and one for caching 
• Put EJB data and HTTP data in the same domain. 
• Use smallest number of replicas as possible 1, 2, or 3 should work in most cases
• Congestion messages can be resolved by increasing the transport buffer size to 50 MB 10 MB is the default. (App Server - <server name > Core Group Service)