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.
Cache replication can take on three forms:
- PUSH - Cache entries for this object are automatically distributed
to the dynamic caches in peer distributed servers. Each cache has a copy of
the entry at the time it is created. These entries cannot store non-serializable
data.
- PULL - Requests data from other servers in the cluster when that
data is not locally present. This mode of replication is not recommended.
- PUSH/PULL - Cache entries for this object are shared between application
servers on demand. When an application server generates a cache entry, it
broadcasts the cache ID of the created entry to all cooperating application
servers. Each server then knows whether an entry exists for any given cache
ID. On a given request for that entry, the application server knows whether
to generate the entry or pull it from somewhere else. These entries cannot
store non-serializable data. Note: The DistributedMap.containsKey() and DistributedMap.keySet()
methods do not show the key that has been broadcasted in the receiving server.
This is because the keys that are stored in a data structure (DRSPushPullTable
table) are different from the backing map that is used by local cache (DistributedMap).
However, the DistributedMap.get(Object key) method will retrieve the value
from the server that broadcasted this key.
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:
- There are too many entries being shared with other servers.
- Not many entries are expiring.
- If you are using the disk offload feature, the disk scan is not running
often to evict the expired entries.
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.
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.