[infinispan-dev] Strict Expiration

[Tristan Tarrant]

On 14/07/2015 14:37, William Burns wrote:
>     I'm even less convinced about the need to guarantee that a clustered
>     expiration listener will only be triggered once, and that the entry
>     must be null everywhere after that listener was invoked. What's the
>     use case?
>
>
> Maybe Tristan would know more to answer.  To be honest this work seems
> fruitless unless we know what our end users want here.  Spending time on
> something for it to thrown out is never fun :(

I see two use-cases related to taking action on expiration:

1. do something with the data before it definitely is removed. This 
could be something like archiving to secondary storage. This particular 
case would also require still having the value to pass to the event 
handler. I don't think we need special guarantees about "only once" but 
it would be a nice-to-have. Also null-after-the-fact wouldn't be a 
requirement.
2. pre-emptive memoization, i.e. a way to implement refreshOnExpiration 
akin to computeIfAbsent. "Only once" would definitely be preferable here 
and. "Null-after-the-fact" is also irrelevant since the code would 
probably end up replacing the existing value.


Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat