On 18 October 2011 18:45, Elias Ross gen...@noderunner.net wrote:
On Tue, Oct 18, 2011 at 10:13 AM, Mircea Markus mircea.mar...@jboss.com
wrote:
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
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
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 -
On Tue, Oct 18, 2011 at 10:13 AM, Mircea Markus mircea.mar...@jboss.com wrote:
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
I've mostly used expiry to control data staleness. For
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
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
On 17 Oct 2011, at 18:21, Dan Berindei wrote:
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
