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.