[infinispan-dev] strictly not returning expired values

Sanne Grinovero sanne at infinispan.org
Tue Oct 18 13:27:14 EDT 2011


On 18 October 2011 18:13, Mircea Markus <mircea.markus at jboss.com> wrote:
>
> 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.

Right I see your point, but is it worth the complexity in the code? I
don't think "staleness" is something which should be controlled this
way; as I said we don't guarantee that we don't return stale values
anyway, so people should not rely on it.
As Dan pointed out by highlighting that change, it might be tricky to
change the eviction thread period alone, but if that is the only
problem I think we can be smarted in that area, at least that's a
background process and we can be creative around that.

As a third reason to change this, is that on the stack of a get() the
client thread might also perform the remove() operation from the
container if it's found stale. So this corner case is heavily
penalized by the cache miss first, and in addition to that it also has
to do more work (than usual).



More information about the infinispan-dev mailing list