[infinispan-dev] strictly not returning expired values

[Dan Berindei]

On Mon, Oct 17, 2011 at 7:51 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> 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.

I don't think this is an option, as a 5 seconds wakeUpInterval was
deemed to short not long ago:
https://source.jboss.org/viewrep/Infinispan/core/src/main/java/org/infinispan/config/Configuration.java?r1=9fe9a8cb6e49308b9e45f09b2f5324a7daefdee3&r2=9cda361dc6df7bcecde95abc31fcbab11f734360

> 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.
>

I guess you could pass in a Clock that lazily calls
System.currentTimeMillis() and saves it for subsequent calls, but that
will complicate things again.

Dan


> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>