[infinispan-dev] New Cache Entry Notifications

Mircea Markus mmarkus at redhat.com
Wed Feb 5 10:40:41 EST 2014


On Feb 5, 2014, at 3:03 PM, Galder Zamarreño <galder at redhat.com> wrote:

> On 05 Feb 2014, at 15:38, Mircea Markus <mmarkus at redhat.com> wrote:
> 
>> 
>> On Feb 3, 2014, at 4:07 PM, Galder Zamarreño <galder 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
>> 
>> Sorry for missing this till now :-) If it was raised that frequently through, must be because people are confused about it. As we're having a major release next, I think we should get this right, even if breaking backward compatibility, and document it as such in the migration guide.
> 
> -1. 
> 
> As already mentioned, the reason why we’ve never this tackled this problem is cos of JCache, which gets listeners right in this area. JCache is about to go final and people should start moving towards that. Redoing our listeners would be a waste of time IMO.

The effort here is minimum, pretty much adding an if statement. The good thing though is that you won't have to raise this on the mailing list again :-)

> You’d be doing some work to fix something people should stop using in near-medium future.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list