[infinispan-dev] Cache entry creation and modification events

[Galder Zamarreño]

--
Galder Zamarreño
Infinispan, Red Hat

> On 14 Oct 2015, at 16:43, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> 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

Why redesign cache notifications? As I mentioned in a previous reply, I see Cache and cache notifications being phased out in favour of: JCache (and its events), ConcurrentMap and Functional Map (and its events) :|. 

So, no need to redesign Cache notifications IMO :|

> 
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev