Read-Through Caching with expiry-delay and near cache (front scheme)

Question

We are experiencing a problem with our custom CacheLoader and near cache together with expiry-delay on the backing map scheme.
I was under the assumption that it was possible to have an expiry-delay configured on the backing-scheme and that the near cache object was evicted when backing object was evicted. But according to our tests we have to put an expiry-delay on the front scheme too.
Is my assumption correct that there will not be automatic eviction on the near cache (front scheme)?
With this config, near cache is never cleared:
             <near-scheme>
                  <scheme-name>config-part</scheme-name>
                  <front-scheme>
                        <local-scheme />
                  </front-scheme>
                  <back-scheme>
                        <distributed-scheme>
                              <scheme-ref>config-part-distributed</scheme-ref>
                        </distributed-scheme>
                  </back-scheme>
            <autostart>true</autostart>
            </near-scheme>
            <distributed-scheme>
                  <scheme-name>config-part-distributed</scheme-name>
                  <service-name>partDistributedCacheService</service-name>
                  <thread-count>10</thread-count>
                  <backing-map-scheme>
                        <read-write-backing-map-scheme>
                              <read-only>true</read-only>
                              <scheme-name>partStatusScheme</scheme-name>
                              <internal-cache-scheme>
                                    <local-scheme>
                                          <scheme-name>part-eviction</scheme-name>
                                          <expiry-delay>30s</expiry-delay>
                                    </local-scheme>
                              </internal-cache-scheme>
                              <cachestore-scheme>
                                    <class-scheme>
                                          <class-name>net.jakeri.test.PingCacheLoader</class-name>
                                    </class-scheme>
                              </cachestore-scheme>
                              <refresh-ahead-factor>0.5</refresh-ahead-factor>
                        </read-write-backing-map-scheme>
                  </backing-map-scheme>
                  <autostart>true</autostart>
                  <local-storage system-property="tangosol.coherence.config.distributed.localstorage">true</local-storage>
            </distributed-scheme>With this config (added expiry-delay on front-scheme), near cache gets cleared.
        <near-scheme>
                  <scheme-name>config-part</scheme-name>
                  <front-scheme>
                        <local-scheme>
                             <expiry-delay>15s</expiry-delay>
                        </local-scheme>
                  </front-scheme>
                  <back-scheme>
                        <distributed-scheme>
                              <scheme-ref>config-part-distributed</scheme-ref>
                        </distributed-scheme>
                  </back-scheme>
            <autostart>true</autostart>
            </near-scheme>
            <distributed-scheme>
                  <scheme-name>config-part-distributed</scheme-name>
                  <service-name>partDistributedCacheService</service-name>
                  <thread-count>10</thread-count>
                  <backing-map-scheme>
                        <read-write-backing-map-scheme>
                              <read-only>true</read-only>
                              <scheme-name>partStatusScheme</scheme-name>
                              <internal-cache-scheme>
                                    <local-scheme>
                                          <scheme-name>part-eviction</scheme-name>
                                          <expiry-delay>30s</expiry-delay>
                                    </local-scheme>
                              </internal-cache-scheme>
                              <cachestore-scheme>
                                    <class-scheme>
                                          <class-name>net.jakeri.test.PingCacheLoader</class-name>
                                    </class-scheme>
                              </cachestore-scheme>
                              <refresh-ahead-factor>0.5</refresh-ahead-factor>
                        </read-write-backing-map-scheme>
                  </backing-map-scheme>
                  <autostart>true</autostart>
                  <local-storage system-property="tangosol.coherence.config.distributed.localstorage">true</local-storage>
            </distributed-scheme>

Answer 1

Hi Jakkke,
The Near Cache scheme allows to have configurable levels of cache coherency from the most basic expiry based cache to invalidation based cache to data versioning cache depending on the coherency requirements. The Near Cache is commonly used to achieve the performance of replicated cache without losing the scalability aspects of replicated cache and this is achieved by having a subset of data (based on MRU or MFU) in the <front-scheme> of the near cache and the complete set of data in the <back-scheme> of near cache. The <back-scheme> updates can automatically trigger events to invalidate the entries in the <front-scheme> based on the invalidation strategy (present, all, none, auto) configured for the near cache.
If you want to expire the entries in the <front-scheme> and <back-scheme>, you need to specify an expiry-delay on both the schemes as mentioned by you in the last example. Now if you are expiring the items in the <back-scheme> for the reason that they get loaded again from the cache-store but the <front-scheme> keys remain same (only the values should be refreshed from the cache store) then you need not set the expiry-delay on the <front-scheme> rather mention the invalidation-strategy as present. But if you want to have a different set of entries in <front-scheme> after a specified expiry delay then you need to mention it in the <front-scheme> configuration.
The near cache has the capability to keep front scheme and back scheme data in sync but the expiry of entries is not synced. Always, front-scheme is a subset of back-scheme.
Hope this helps!
Cheers,
NJ