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

[Dan Berindei]

On 25 Jan 2013 23:26, "Vladimir Blagojevic" <vblagoje at redhat.com> wrote:
>
> Hey,
>
> I figured out why cache listeners notifications were not fired. We have
> to add listener *after* cache.start() has been called. If listener is
> added before start it will not be registered.
>

This doesn't sound right... DefaultCacheManager calls cache.start()
automatically, so you should never have to call it explicitly.

Looking at the code, the listener should be registered even if the cache
wasn't started yet (e.g. ListenerRegistrationTest never calls start()). The
only odd thing is that if you stop a cache, all the listeners are lost.
Maybe that's what happened in your case?

> That aside I found some problems mapping our events to jsr 107 events.
> The problem is specifically with JSR107 CacheEntryCreatedListener and
> CacheEntryExpiredListener.
>
> The first one is not easy to implement because we need both key/value
> pair for jsr listener and our CacheEntryCreatedEvent does not provide
> value. I found some references where people used CacheEntryModified
> instead with pre being null and post being value to detect new entry in
> cache. In that case listener translator class would have to keep state
> and track pre(true/false) for CacheEntryModified, right? Any other way
> to do it?
>

You could add an interceptor to trigger your events, without using the
cache's notifications  at all.

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.


> 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).

Come to think of it, if an entry is evicted because of size constraints,
there isn't any way to keep track of its expiration time and invoke the
expiration listener on access either. Is the expiration event mandatory in
the JSR?

Cheers

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130128/74d601ba/attachment.html