CacheLoader.loadAll optimization to include equivalent of getBackingMapEntries or getReadOnlyEntries (Doc ID 2695515.1)

Last updated on OCTOBER 20, 2023

Applies to:

Symptoms

Customer had reported that CacheLoader.load being 'eagerly' called. This behavior is symmetrical with the load that occurs via the root NamedCache.aggregate call. For example, NamedCache.aggregate ([foo, bar], new Count ()) will load foo and bar if they are not in the cache. Equally, the getReadonlyEntry behaves the same. If you want to operate only on entries that are present, you should use the PRESENT_ONLY aggregator characteristic. We do not have an equivalent of getBackingMapEntries or getReadOnlyEntries (multi variants of the singular methods). We could certainly add this to the product to allow you to optimize for the loadAll case.

As a workaround, you could use an invokeAll and/or enlist the entries that you want to perform a loadAll against. Once enlisted you could then call CacheLoader.loadAll directly and populate the associated entries. However,
while this is an option it is incredibly hacky and would prefer that you simply use the getBackingMap API and call getAll until we have a suitable alternative for you.

However,
1. If I do invokeAll/aggregate with collection of the keys, if some of them are missing from cache, they can be bulk loaded from DB/cacheloader, assumption is if I requested those keys for the process, the values will be used, so it should be more efficient to bulk load.
2. If I already in an entry process/aggregator, and need access affinitive cache via BackingMapContext, there should be a way to do bulk load as well. Currently only one entry can be accessed at a time.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.