[infinispan-dev] Cache entry creation and modification events

[Dan Berindei]

On Mon, Oct 19, 2015 at 5:34 PM, Galder Zamarreño <galder at redhat.com> wrote:
>
>
> --
> 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) :|.

How is the ConcurrentMap API different from the Cache API?

>
> So, no need to redesign Cache notifications IMO :|

I was assuming JCache listeners are implemented on top of the Cache
listeners, so they would need fixes in the Cache listeners to work
properly.

We could implement the JCache listeners directly in 9.0 and remove the
Cache listeners, I guess. But looking at the JCache API it looks like
their listeners need the previous value for all writes, unlike the
FunctionalMap listeners, so I think there will still be a need for a
lower-level implementation.

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