[infinispan-dev] strictly not returning expired values

Sanne Grinovero sanne at infinispan.org
Mon Oct 17 12:51:10 EDT 2011


I've noticed that every time we perform a get() operation (or any
other retrieval) the value is NOT returned to the client if it's
expired, which is going to receive a null instead.

It looks like that these checks are in place to prevent
a) a race condition with the eviction process
b) to not return very old values from a very large "wakeUpInterval"
between eviction activity
c) to load from cacheLoaders

Now for the first case, as a user of a caching library I would prefer
to get the value instead. Expiry is in place only to prevent me from
wasting memory, but this entry wasn't collected yet so why is
Infinispan denying me access to the value I want to retrieve? We're
introducing unneeded cache misses.

Since even with the current code we can not provide guarantees that we
won't ever return an expired entry (between  the check and the actual
return to user code we might be briefly suspended), I don't see why we
should not make it clear that the expiry timeout is a best-effort time
and relax our code checks a bit; there are many reasons to do so:

1) avoid fictitious cache misses.

2) Avoid the need to invoke a System.currentTimeMillis() for each
retrieval operation - that's expensive!

3) Some operations like size() or values() now explicitly iterate the
whole result set twice to make sure all expired entries are removed.
This is unnecessary following the reasoning above.

Regarding the other cases:
b) We don't need to care imo. If people need more precision they
should use a lower wakeUpInterval.
c) We should keep this logic in CacheLoader, just because having an
aggressive wakeUpInterval might be very expensive in this case.

I'm asking as I've built a quick POC for ISPN-1459 but since now the
current time needs to be passed to the entry, I end up needing to
invoke the wall clock even for immortal cache entries making many
other use cases slower: not happy with that, I'd rather speed up both
use cases.

Sanne


More information about the infinispan-dev mailing list