On Mon, Jan 28, 2013 at 5:41 PM, Manik Surtani <msurt...@redhat.com> wrote:
> > On 28 Jan 2013, at 15:22, Vladimir Blagojevic <vblag...@redhat.com> wrote: > > On 13-01-28 7:31 AM, Manik Surtani wrote: > > If you're ok with changing the core, you could add a getValue() method > to CacheEntryCreatedEvent, and an isCreated() method to > CacheEntryModifiedEvent (as I suppose you don't want to call the updates > listener when an entry is created). Both changes should be > backwards-compatible. > > That could work. > > > The second one Manik? As I was researching how to do this I found you were > against the first option https://issues.jboss.org/browse/ISPN-881 > > > Yes, isCreated(). > > > > > 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. I think you'd need something like a cache store that only keeps the keys and their expiration time, and with passivation enabled. I don't think you can reuse the cache store code, though.
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev