[infinispan-dev] strictly not returning expired values

[Mircea Markus]

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.