load vs loadAll when using refreshAfterWrite

[NathanHazout]

Let's start with an example:

I am calling getAll on 40 keys.

• 10 keys are missing entirely
• 10 keys are expired
• 10 keys are passed their refresh time
• 10 are present

I think it's clear that caffeine will call my loadAll on the missing and expired keys.
What is not clear is what will it do about the keys that need to be refreshed. Will it do a separate loadAll call for them? Will it do 10 load() calls?

[ben-manes]

Yeah, bulk refresh is very confusing (#7). What you probably want is to look at the coalescing bulkloader example. Caffeine doesn't directly offer any bulk refresh logic so it will otherwise perform 10 load() calls.

A getAll that has the opportunity to bulk refresh is likely much rarer than parallel get calls for distinct keys, but wouldn't naturally fall into a case where the cache could call loadAll instead. The coalescing approach over a time/space window handles both getAll and get cases uniformly, and if using a library like Reactor then its trivial glue code. This is nice because refreshes are optimistic, async loads so a small buffering delay won't impact user-facing latencies and could reduce the resource's load.

A refresh calls the asyncReload(key, oldValue, executor) method of your CacheLoader, which by default delegates to wrap load(key). That allows for neat tricks like optimizing the reload if its expensive, but the value is versioned and you can cheaply check if its unchanged at the source. However then if that and loadAll were both overridden, which is called might be unclear but the likely expectation is to honor your reload method. So then we'd need an asyncReloadAll and smart routing based on what is redefined. In the end because it only optimizes a getAll its a lot of confusion for little value, whereas coalescing is more broadly useful and obvious. Hence why bulk refresh was a nice idea but abandoned as the wrong approach.