copying all new-keys/updated-keys to remote cache without eviction

[myfrndjk]

Hi,

I am using caffeine_local + redis_remote

Currently i am using loading cache and set a maximumSize. After maxSize is reached overflow contents are moved to remoteCache

Some of my cacheInstance never reach its maxSize [My maxSize is 100 but i put only 50 elements], so this 50 elements never moved to remoteCache and this is creating consistency issues

Do we have anything like NewElementListner for example when ever a element is added/updated in local i can send that to remoteCache.

I can directly send one copy to remote like below but

caffine.add( element, elemnet_value)
redis.add( element, elemnet_value)

I am seeing if it is possible to do

caffine.add( element, elemnet_value) ---> updateEementListner ---> redis.add( element, elemnet_value)

Do we have such component updateEementListner so that all the elements in local can be moved to remote ?

seems cache2k is providing this feature unfortunately I dont find examples for caffeine/not sure this feature is available or not

    Cache2kBuilder.of(Integer.class, Integer.class)
      .addListener(new CacheEntryCreatedListener<Integer, Integer>() {
        @Override
        public void onEntryCreated(final Cache<Integer, Integer> cache,
                                   final CacheEntry<Integer, Integer> entry) {
          System.err.println("inserted: " + entry.getKey());
        }
      });

Thanks
Jk

[ben-manes]

In Caffeine you would use a computation which is more flexible and less error prone. As in,
cache.asMap().compute(key, (k, v) -> /* update and notify */)
There are various benefits of this approach.

A caller may not always want to notify the listener(s), which leads to the "quiet" methods like those in Ehcache. This can be confusingly named, such as JSR-107's Cache.clear() will not invoke the listener and Cache.removeAll() is used in order to. These are all or nothing, so if one listener should be skipped then that cannot be done easily.

Some listeners need to be performed atomically as part of the operation whereas others can be asynchronous and, if asynchronous, some may need to be invoked in key-order (handle key1=a before key1=b) or multiple events can be batched for more efficient processing. Those are configuration constraints that are not always offered by the frameworks. Instead it is much easier to do this in code by how the listener is invoked, e.g. combining with a reactive streams library to handle all of the async cases trivially.

A major philosophy difference is whether the cache is an implementation detail or an application framework. Caffeine views it as another Java collection like ConcurrentHashMap, where it should be flexible to solve the business logic but not exposed outside of the component's interface (other than registering for stats or similar). Alternatives may advocate for breaking encapsulation by obtaining it from the CacheManager directly to manipulate the cache or attach their own listeners at runtime. That turns it into a data store, like an ORM, that is independent of the business logic akin to joining common sql table at different parts of the application (e.g. a distributed in-memory data grid). That adds a lot of lifecycle and resource management complexity, and makes the cache an architectural pillar in the application. Caffeine is just a fancy ConcurrentHashMap, others have built those layers above it when desirable.

The convenience of a create and update listeners are narrow, brittle, and can introduce confusing apis or situations. Since the cache will evict automatically we offer that listener, but beyond that it tends to undesirable scope creep. Instead there is the flexibility to layer that on top of the cache since you understand your use-cases best, can tailor the logic for that, and encapsulate the cache to avoid surprises.

[adwsingh]

Also checkout Redis support for client side caching, https://redis.io/docs/manual/client-side-caching/