[infinispan-dev] strictly not returning expired values

[Sanne Grinovero]

On 18 October 2011 18:45, Elias Ross <genman at noderunner.net> wrote:
> On Tue, Oct 18, 2011 at 10:13 AM, Mircea Markus <mircea.markus at 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 example, I
> would hold a token for security validation. It wasn't entirely
> necessary to have a high degree of accuracy, maybe an order of a few
> seconds. But in many cases if the expiry thread runs every minute I
> suspect this would be too long.
>
> In my original implementation of expiration for JBoss TreeCache I used
> a heap (priority queue) to order entries. This kept the implementation
> very fast, at the expense of memory usage of course.
>
> I agree that doing removals during data access is a very bad idea.
>
> I would suggest having two user options: 1) Infrequent expiration
> scans 2) Or, use of a priority queue and more frequent scanning.

Thanks Elias, feedback from a real use case is exactly what I was needing most.

Security tokens is an interesting application; wouldn't it make sense
for you to store a timestamp in your value too, and check on that as
well? (in combination with automatic expiration).

Your suggestions are what I would do too; not sure about the priority
queue exactly, but the solution clearly is in making the eviction
process more efficient - a priority queue might be a way, or anything
else which might make the eviction process quicker. It seems we're
discussing implementation details in the other thread "Time
measurement and expiry", so I'll give more details there but one of
the reasons for me to start these discussions is that if I'm allowed
to make these changes, then the eviction process will be much faster
as a consequence of not invoking the wall clock at every entry of the
cache.
How much faster, that's to be measured yet.. focusing this thread on
the use cases, what sort of precision would you expect? Should we try
to stay under a single second for an average heap (and how big is
that?) to be considered "correct" ?