Is there a reason getAll() does not lock the data loading like the getOne()?

[krishna81m]

Is there a reason getAll() does not lock and multiple concurrent requests can trigger expensive bulkLoad at the same time? By default, was expecting com.github.benmanes.caffeine.cache.LocalManualCache#getAll to lock on a concatenated String of sorted keys, or the first key in the collection or may be even pass a custom key/lock builder as part of the cache may be?

The only other option is to write our own wrapper on top of LoadingCache to delegate all but some expensive methods like getAll().

It would be nice to add a lockBuilder() from the collection of keys or even lock on a custom key to be loaded?

[ben-manes]

This is discussed in the FAQ. Does that help?

A blocking bulk load is supported by AsyncCache because it can insert an in-flight entry immediately. Unfortunately for a synchronous this is not possible, as we lock through ConcurrentHashMap which does not allow a caller to compute multiple entries at once. Usually the async cache is a good fit since expensive calls can mean remote calls so per-entry futures fits the mental model.

[krishna81m]

The reason I suggested a LockBuilder as a feature in LocalLoadingCache is that the default fetch one at a time or a custom loadAll() may not be optimal when the keys are huge in number and should be fetched in batches locking a few keys at a time. Below LocalLoadingCache.getAll() requires a custom lock even before calling getAll() as it simply fetches in bulk at a time and two requests can fetch without realizing both are doing cacheLoader.loadAll() unnecessarily. This part of concurrency is not clear.

default Map<K, V> LocalLoadingCache.getAll(Iterable<? extends K> keys) {
  return hasBulkLoader() ? loadInBulk(keys) : loadSequentially(keys);
}

Sure, LocalAsyncLoadingCache makes sense with its locking capability creating/returning Futures and populating them by overriding asyncLoadAll(keys...) to optimize the fetch and not require custom wrapper/locks on top of this. But, this comes with an additional overhead of another Executor.

Related discussion: #310

[ben-manes]

You can specify a same-thread executor for the async cache, which will behave as you desire. When virtual threads finally arrive then it won't be a concern anyway, but that is still a ways off.

Regardless, the only way to support this is by having a placeholder object in the map that is locked against independently. We do this with futures in AsyncCache. In a synchronous cache we rely on ConcurrentHashMap, which uses ReservationNode as its lock object. However since it does not support bulk operations and we do not fork the hash table, that is not an option here. I think you could bring up this feature for Doug Lea's consideration on concurrency-interest.