-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache.getAll fails to trigger refresh #971
Comments
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: - |
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: |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: