[infinispan-dev] Cache entry creation and modification events

[Dan Berindei]

There is one more thing to consider: the interface for acting on the
previous value of an event is very clunky even today. It basically
requires a thread-local to keep track of the previous value from the
pre=true invocation to the pre=false invocation, and even that won't
work once the reactive interceptor stack lands (so that pre and post
events are triggered on different threads).

So I'm starting to think we should go with option 1 for now, and start
a bigger redesign of the cache notifications for 9.0:
* Remove the pre=true events
* Add explicit event properties for the previous value/metadata

Without backwards compatibility requirements, we could even add a
skipPreviousValue parameter to all listener annotations -- except for
@CacheEntryCreated, I guess -- making the new listener type
superfluous.

Cheers
Dan


On Mon, Oct 12, 2015 at 11:02 AM, Dan Berindei <dan.berindei at gmail.com> wrote:
> On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman at gmail.com> wrote:
>>
>>
>> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:
>>>
>>> I'm not sure about including removals/invalidations/expiration,
>>
>>
>> Invalidations to me don't quite fit, since it should be passivated in that
>> case.
>
> Passivations have a different listener, I didn't include
> @CacheEntryPassivated here :)
>
> Perhaps invalidation doesn't fit, because it's used to remove stale
> entries either after a rebalance, or after a write (for L1 entries, or
> in invalidation mode).
>
> But then I would say expiration also doesn't fit, because the all the
> others are direct actions by the user, and expiration happens in the
> background.
>
>>
>>>
>>> because there would be no way to say "I want to be notified on
>>> creation and modification, but no removals". On the other hand, adding
>>
>>
>> We could always add a parameter to the new annotation to say if you don't
>> care about removals maybe?
>
> Yes, that should work.
>
>>
>>>
>>> 3 more methods delegating to the same implementation, while not
>>> pretty, does allow you to listen to all changes.
>>
>>
>> Do we need 3 methods?  Yes I think it would be nice for people.
>
> I'm assuming the listener methods are checked to receive the right
> event types. If we allow supertypes (and make CacheEntryWrittenEvent a
> supertype of the others) it could be just 1 method with 4 annotations.
>
>>
>>>
>>>
>>> Or are you thinking that the 3 additional listeners would add
>>> significant overhead when clustered?
>>
>>
>> I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
>> new event in addition to the existing ones.
>
> Right, if we include the removals in this annotation there would be
> just one listener. But would it be faster than having 4 listeners, one
> for create/update, and one each for remove/invalidation/expiration?
>
> Cheers
> Dan