[infinispan-dev] New Cache Entry Notifications

[Galder Zamarreño]

On 03 Feb 2014, at 17:29, William Burns <mudokonman at gmail.com> wrote:

> On Mon, Feb 3, 2014 at 11:07 AM, Galder Zamarreño <galder at redhat.com> wrote:
>> 
>> On 23 Jan 2014, at 18:54, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> 
>>> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman at gmail.com> wrote:
>>> 
>>>> Hello all,
>>>> 
>>>> I have been working with notifications and most recently I have come
>>>> to look into events generated when a new entry is created.  Now
>>>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>>>> However we currently raise a CacheEntryModifiedEvent event and then a
>>>> CacheEntryCreatedEvent.  I notice that there are comments around the
>>>> code saying that tests require both to be fired.
>>> 
>>> it doesn't sound right to me: modified is different than created.
>> 
>> I've lost count the number of times I've raised this up in the dev mailing list :|
>> 
>> And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in order to differentiate between a modify and a create without breaking backwards compatibility and expectations of events to be received. Just need to trace back the jira issue number, and associated forum threads ;) :p
> 
> Ah nice I didn't even notice the method until you pointed it out.
> 
>> 
>>> 
>>>> 
>>>> I am wondering if anyone has an objection to only raising a
>>>> CacheEntryCreatedEvent on a new cache entry being created.
>> 
>> It'd break expectations of existing applications that expect certain events. It's a very difficult one to swallow.
> 
> I agree. Maybe I should change to if anyone minds if Cluster Listeners
> only raise the CacheEntryModifiedEvent on an entry creation for
> cluster listeners instead?  This wouldn't break existing assumptions
> since we don't currently support Cluster Listeners.  The only thing is
> it wouldn't be consistent with regular listeners…

Yeah, it’s a tricky one. You don’t wanna raise both cos that’d be expensive to ship it around for no extra gain. If you are going to choose one that’d be CacheEntryModifiedEvent indeed. I think we can break off here for clustered listeners specifying it clearly. I don’t think there’s much point in creating a new set of listeners/event/annotations for the clustered option since eventually we should move towards JCache listeners and only have custom ones for the extra stuff we provide callbacks for.

> 
> 
>> 
>> Plus, there's JCache specifications, which adds listeners, and gets them right. Eventually everyone should move towards that.
> 
> Just to be clear you are saying the JCache only raises a single event
> for change and create right?

Yeah, see JCacheListenerAdapter class.

> 
>> 
>>>> Does
>>>> anyone know why we raise both currently?
>> 
>> Legacy really.
>> 
>>>> Was it just so the
>>>> PutKeyValueCommand could more ignorantly just raise the
>>>> CacheEntryModified pre Event?
>>>> 
>>>> Any input would be appreciated, Thanks.
>>> 
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org)
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> --
>> Galder Zamarreño
>> galder at redhat.com
>> twitter.com/galderz
>> 
>> Project Lead, Escalante
>> http://escalante.io
>> 
>> Engineer, Infinispan
>> http://infinispan.org
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org