Cache replication

With replication, data is generated one time and copied or replicated to other servers in the cluster, saving time and resources. Caching in a cluster has additional concerns. In particular, the same data can be required and generated in multiple places. Also, the permission the resources need to generate the cached data can be restricted, preventing access to the data.

Cache replication deals with these concerns by generating the data one time and copying it to the other servers in the cluster. It also aids in cache consistency. Cache entries that are not needed are removed or replaced.

The data replication configuration can exist as part of the Web container dynamic cache configuration accessible through the administrative console, or on a per cache entry basis through the cachespec.xml file. With the cachespec.xml file, you can configure cache replication at the Web container level, but disable it for a specific cache entry.

[z/OS] You can configure cache replication on a base server that has multiple servants enabled or on servers that are in a clustered environment. If you enable cache replication in a clustered environment, the replication occurs among all of the servants even if only a single server in the cluster is active.

Cache replication can take on three forms:

The dynamic cache service broadcasts cache replication updates asynchronously, based on a configurable (batch update interval on the dynamic cache service administrative console panel ) rather than sending them immediately, when they are created. Invalidations are sent immediately. Distribution of invalidations prevents stale data from residing in a cluster. For more information about configuring cache replication, see Configuring cache replication and Dynamic cache service settings.

Attention: In PUSH/PULL mode, the cached object is kept locally on the server that creates it; however, other servers also use the cache ID and store it in the DRSPushPullTable table. If a remote server needs the object, it requests the object by cache ID, or name, from the creating server. Each cache instance has one DRSPushPullTable table that is associated with it. The following conditions cause the DRSPushPullTable table to grow too big:
Use the following suggestions to resolve the issue:
  • Increase the heap size to 1.5 GB or 2 GB, if possible.
  • Maintain better distribution for the expiration time of entries, for example:
    • 20% of the entries never expire.
    • 30% of the entries expire in 3600 seconds.
    • 30% of the entries expire in 600 seconds.
    • 20% of the entries expire in 60 seconds.
  • [Version 6.0.2] When you use the disk offload feature in WebSphere® Application Server Version 6.0.2 or earlier, adjust the disk cleanup frequency to an optimal value. For example, about 20% of the entries expire at that time.



Related tasks
Configuring cache replication
Related reference
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 9:31:45 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=cdyn_cachereplication
File name: cdyn_cachereplication.html