Using ValueCache without any in-memory cache

[kirkobyte]

Hello 👋 It's my understanding that setting a Value Cache does not disable the default in-memory cache map. Is this correct?

If so, what is the official supported way to perform caching exclusively via the Value Cache? Is it .setCacheMap(null).setValueCache(myValueCache)?

[bbakerman]

The method org.dataloader.DataLoaderOptions#cachingEnabled controls Future caching - that is an in memory map of CompletableFutures was have returned before per key. The naming could be better but was invented when we ONLY had a futures cache and no value cache.

So you would do

DataLoaderOptions options = DataLoaderOptions.newOptions().setCachingEnabled(false).setValueCache(myValueCache); 

[bbakerman]

A better ideal world of naming would have

DataLoaderOptions options = DataLoaderOptions.newOptions().setFutureCachingEnabled(false).setValueCache(myValueCache); 

but backwards compatibility matters

[kirkobyte]

Hi @bbakerman 👋 I had tried this out locally, and it seemed like setCachingEnabled(false) also disabled the ValueCache.

When I set up my DataLoader with this configuration, breakpoints set in MemcachedValueCache never got hit:

 return RegisteredLoader.builder() .name(EditorialQualityScoreLoader.NAME) .dataLoader( DataLoaderFactory.newMappedDataLoader( new MyLoader(myClient), DataLoaderOptions.newOptions() .setCachingEnabled(false) .setValueCache( new MemcachedValueCache<>( memcacheClient, EditorialQualityScores.class, getTtl(environment))) .setMaxBatchSize(MAX_BATCH_SIZE))) .build();

However, I did manage to find a workaround, by setting the CacheMap to this NoopCacheMap:

public class NoopCacheMap<K, V> extends DefaultCacheMap<K, V> { @Override public boolean containsKey(Object key) { return false; } }

[kirkobyte]

Could it be that I got something wrong in my MemcachedValueCache implementation or that it needs to be implemented using Try for improved invalidation?

[bbakerman]

I was doing a code inspection to work out the "disabled" ness - its possible there is more logic controlling it.

I would need to do a reproduction test case - which I didnt do - to confirm.