Associate a server to replication domain | Other options to ensure cache content consistency across cluster
Configure sharing policy in cachespec.xml
In some instances, you may want to overwrite the replication type configured in the administrative console. For example, to further reduce the overhead of sending too many DRS messages, you can choose to let each server generate its own cache and not share it with other cluster members. You can do so by setting the sharing-policy element to not-shared for the specific cache entry in cachespec.xml. Note that invalidation DRS messages are still replicated to all cluster members so the cache content on every server is valid. If this element is not present, then it defaults to the replication type configured in the administrative console.
This property does not affect distribution to Edge Side Include processors through the edge fragment caching property.
The sharing policy in the cachespec.xml maps to replication type defined in the administrative console as follows:
- not-shared (cachespec.xml) and Not Shared (console)
Cache entries for this object are not shared among different application servers. These entries can contain non-serializable data. For example, a cached servlet can place non-serializable objects into the request attributes, if the <class> type supports it.
- shared-push (cachespec.xml) and Push only (console)
Cache entries for this object are automatically distributed to the dynamic caches in other application servers or cooperating Java virtual machines (JVMs). Each cache has a copy of the entry at the time it is created. These entries cannot store non-serializable data.
- shared-push-pull (cachespec.xml) and Both push and pull (console)xxxx
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.
The following example shows a sharing policy of not-shared:
<sharing-policy>not-shared</sharing-policy>