Use and Limitations of Custom Coherence File Based Cachestores (Doc ID 1408503.1)

Last updated on DECEMBER 04, 2024

Applies to:

Goal

You have a requirement to configure the clustered persistence using the "Partitioned cache of a file based Cachestore” for persisting the cache permanently to make sure the cache is persisted even if the servers are brought down.

Coherence Configuration:

There is a Coherence cluster with two Coherence members which are running on two different machines. The cluster is configured to use distributed cache with read-write-backing-map-scheme such that each Coherence server will have its own custom file based CacheStore to persist/store the cache.

While the distributed cache is being used the cache store method will be called from within each of the Coherence servers for the records that hold the primary copy, as a consequence the cache servers’ respective custom file based CacheStores will be expected to have non-identical records (i.e. the custom cachefilestores are not synchronized).

A potential problem with this configuration is that in case the entire Coherence cluster is restarted and cache performs a read-through operation, the caches may be loaded with data that may not represent the latest version of the entries.

The following questions are frequently asked in regards to the aforementioned distributed cache behavior:

1. File based CacheStores are not in synchronization; is it distributed cache topology limitation?
2. Is there any way we can synchronize both the custom filestores?
3. In case of Coherence cluster restart, how can we ensure both the custom filestores are in synchronization and clients get the latest cache data whenever cache does a read-through from respective cache store?

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.