>>>> >>>> > The second I have no idea how to implement as we do not have >>>> > CacheEntryExpired event. True, spec is not rigorous that such an event >>>> > has to be fired immediately after an entry has expired but eventually >>>> > (which might be on access). Either way, I am all ears on suggestions how >>>> > to implement this one. >>>> > >>>> >>>> I guess @CacheEntryEvicted/@CacheEntriesEvicted would be the closest thing >>>> we have in Infinispan. But you can't check in the listener if the entry >>>> was evicted because it expired or because there wasn't enough space in the >>>> data container (yet). >>> There could definitely be something clever we could do here. Adding the >>> (expired or evicted) entry to a queue for later notification. But that >>> would definitely need to be something we explicitly enable rather than have >>> running all the time, since it kinda defeats the purpose of evicting >>> something to save memory only to have it put in a different queue elsewhere >>> until an event is fired. >> >> Exactly! One thing we could do is what RI does. Check for expired on entry >> access from JSR module and during normal expired cleanup cycle..... > > Be mindful of performance considerations here - this could get very expensive. > > > Exactly. I don't think you can use a queue for later notification, because > you also have to cancel the notification if the user updates the same key > again. I mean if an entry was supposed to expire at 12:00 and the user did a > put at 12:59 with expiration time 12:30, then he shouldn't get an expired > notification at 12:00 - even if the entry was evicted in the meantime.
Yes; definitely not a simple thing to do. -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
