On Mon, Oct 17, 2011 at 7:51 PM, Sanne Grinovero <sa...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev