[infinispan-dev] New Cache Entry Notifications
Mircea Markus
mmarkus at redhat.com
Tue Jan 28 17:48:02 EST 2014
On Jan 27, 2014, at 9:35 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
> On 23 January 2014 17: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'd tend to agree with you, still it's a matter of perception as I could say
> "a key is changing value from null to some new value so it's an update"..
> I realize it's a bit far fetched,
there were actually discussions about implementing all the ISPN operations as a single generic one, so you do have a point :-)
> still if you start introducing
> tombstones for eventual consistency you can have a longer history of
> changes to append to even if it's just a "creation".
Whilst I agree with you in theory, IMO the users have a clear expectations on what an update vs an create is (as in CRUD). Using tombstones is an implementation detail, but there is a general accepted semantical difference between a create and an update.
>
> For example with this sequence of commands:
>
> Put(K1, V1), Remove(K1), Put(K1, V2) < Creation event?
>
> As the history sequence for this entry is
> V1 - null - V2
>
> And in case of asynchronous CacheStores, Remote eventlistener, X-site,
> .. and all other features where you might have coalescing of changes
> applied, this sequence could be "compacted" as
>
> V1 - V2
>
> Is the write of V2 still a creation event?
>
> I don't necessarily disagree with the choice, but it's not that simple
> and will have consequent complexities down the road.
>
> Personally I think you should drop the differentiation between the two
> event types, as it's over-promising on something that we can't deliver
> consistently.
>
> Sanne
>
>>
>>>
>>> I am wondering if anyone has an objection to only raising a
>>> CacheEntryCreatedEvent on a new cache entry being created. Does
>>> anyone know why we raise both currently? 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
More information about the infinispan-dev
mailing list