Re: [infinispan-dev] Cache entry creation and modification events

-- Galder Zamarreño Infinispan, Red Hat > On 14 Oct 2015, at 16:43, Dan Berindei <dan.berindei(a)gmail.com&gt; 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(a)gmail.com&gt; wrote: >> On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman(a)gmail.com&gt; wrote: >>> >>> >>> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev