Original comment posted by fry@google.com on 2012-04-18 at 07:19 AM

This raises the interesting point that currently getAll/loadAll doesn't trigger refresh if a custom loadAll implementation is provided.

I agree that with a custom loadAll method it would be somewhat tragic to trigger hundreds of independent refreshes. So maybe this is arguing for CacheLoader.reloadAll.

Original comment posted by wasserman.louis on 2012-04-22 at 05:42 PM

I have to admit that I find it surprising that getAll doesn't trigger refreshes -- and I suspect users would, too...

Original comment posted by kevinb@google.com on 2012-05-30 at 07:45 PM

(No comment entered for this change.)

Labels: -Type-Enhancement, Type-Addition

Original comment posted by outdooricon on 2012-09-11 at 03:27 PM

"getAll/loadAll doesn't trigger refresh if a custom loadAll implementation is provided."

Really glad that I read this... I haven't seen this documented anywhere. As a user, I definitely expected a refresh. I'm using loadAll to populate multiple entries in the cache using only a single db call. This is my use-case for needing a reloadAll as well...

Original comment posted by kevinb@google.com on 2012-11-09 at 11:21 PM

Issue #1201 has been merged into this issue.

Original comment posted by kevinb@google.com on 2012-11-09 at 11:23 PM

Charles and I like this plan now: After getAll() determines which keys we already have in the cache, it could check which of those are already stale, and include those in the set it queries. If any of those don't happen to come back, we still use the stale values for those.

Status: Accepted
Labels: -Type-Addition, Type-Defect

Original comment posted by kevinb@google.com on 2013-03-12 at 06:43 PM

(No comment entered for this change.)

CC: fry@google.com

I am facing the same issue with cached calls to database. The status of the issue is accepted. Are there any news about the developpement of a solution?

This should work properly in the rewrite. There should probably be variants of these tests for the async cache, though. A bulk refresh is not supported yet.

I have still the same problem. Automatic refresh calls only load and not loadAll.

[main] INFO com.jcabi.aspects.aj.NamedThreads - jcabi-aspects 0.22.1/58f97a9 started new daemon thread jcabi-loggable for watching of @loggable annotated methods
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #loadAll('[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]'): '{0=0, 1=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=7, 8=8, 9=9}' in 162,75µs
[main] INFO com.dichotomia.tests.guava.CacheExample - #getAll([[0‥10)]): '{0=0, 1=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=7, 8=8, 9=9}' in 17,07ms
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(0): '0' in 30,96µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(1): '1' in 17,88µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(2): '2' in 11,85µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(3): '3' in 8,43µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(4): '4' in 18,06µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(5): '5' in 23,26µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(6): '6' in 21,23µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(7): '7' in 9,26µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(8): '8' in 7,80µs
[main] INFO com.dichotomia.tests.guava.CacheLoaderExample - #load(9): '9' in 7,87µs
[main] INFO com.dichotomia.tests.guava.CacheExample - #getAll([[0‥10)]): '{0=0, 1=1, 2=2, 3=3, 4=4, 5=5, 6=6, 7=7, 8=8, 9=9}' in 12,03ms

For my side this is documented as #7 to support bulk refresh. I'm wrapping up v2 and not sure if this will make it.

Hey, Is there an alternate way to trigger this other than calling refresh on all the keys periodically?

Not sure where we left this. It seems like better docs would be good, but behavior changes are unlikely now that we point people to Caffeine.