javaguava

Guava CacheLoader - invalidate does not immediately invalidate entry if both expireAfterWrite and expireAfterAccess are set


So for example:

CacheBuilder.newBuilder()
            .maximumSize(1000)
            .expireAfterAccess(1, TimeUnit.MINUTES)
            .expireAfterWrite(1, TimeUnit.MINUTES)
            .build(new CacheLoader<String, Object>() {
                @Override
                public Object load (String key) {
                    return ...;
                }
            });

If calling invalidate(key) on the returned instance, a subsequent call to getUnchecked() will ALWAYS use the previous value until at least 1 minute has passed in which cause it will call load(key) again. A call to cleanUp() right after invalidate() seems to have no effect either.

Am I using this feature incorrectly or not understanding something about how the caching is working?

Per http://code.google.com/p/guava-libraries/wiki/CachesExplained:

"At any time, you may explicitly invalidate cache entries rather than waiting for entries to be evicted. This can be done:

individually, using Cache.invalidate(key)"

I would assume that the call to invalidate would take precedence and always make the entry be eligible for eviction (ie, the very next getUnchecked call) even if the time is less than 1 minute.

Edit:: I figured out my issue. The above observation is indeed true and the expected nature of the cache. However, my specific was issue was that I was sometimes calling invalidateAll([]) with an empty List (which doesn't invalidate anything), when I really needed to call invalidateAll() with no parameters (which invalidates everything). I would almost expect invalideAll([]) to be equivalent to invalidateAll(), but I could see where that would lead to some confusion.


Solution

  • ...I'm not clear whether you're describing your expectations or your observations, but invalidate should remove the entry immediately -- not waiting for another query -- and should force the value to get reloaded on the very next query to that key. If that's not what happens, then that's a bug.