On 18 Oct 2011, at 12:05, Sanne Grinovero wrote: > Not because of the cost of reading the clock, my main motivation is > that we artificially create cache misses which might be very expensive > to the client code. > > On top of that, the fact that this check also has a cost - not arguing > how low - makes me wonder even more. > > As I see it, it's unavoidable for a cache to provide a cache miss when > the data is gone, like GC'd, and we're not able to return it. It's > also reasonable to expire values and remove them to make sure we don't > run out of memory - but if there's a chance in which the value was not > garbage collected and we're able to return it, we should return it. The way I see it a user might configure an expiry for two reasons: - to manage memory and/or - to control how much "staleness" the data it uses might have
IMO this is something the user must decide on a use case by use case basis, hence I think a config would be better. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
