_Original issue created by wasserman.louis on 2012-04-15 at 02:31 PM_
http://stackoverflow.com/questions/10153724/google-guavas-cacheloader-loadall-vs-reload-semantics motivated the question of how one could do efficient bulk refreshes, if LoadingCache.getAll discovered many entries eligible for refresh.
There's clearly a sensible default implementation -- just do the asynchronous refreshes concurrently, as it's done now -- but I'm curious if it might merit its own method that can be overridden, and if that'd overly complicate the already-rather-complex Cache semantics.
_Original comment posted by [email protected] 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 [email protected] 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 [email protected] on 2012-11-09 at 11:21 PM_
_Issue #1201 has been merged into this issue._
_Original comment posted by [email protected] 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 [email protected] on 2013-03-12 at 06:43 PM_
_(No comment entered for this change.)_
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.
Most helpful comment
_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...