Re: [infinispan-dev] Strict Expiration
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