[infinispan-dev] Translating our events to JSR 107 events

[Dan Berindei]

On Mon, Jan 28, 2013 at 5:41 PM, Manik Surtani <msurtani at redhat.com> wrote:

>
> On 28 Jan 2013, at 15:22, Vladimir Blagojevic <vblagoje at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130129/36a2b02a/attachment.html