[infinispan-dev] Cache entry creation and modification events

[William Burns]

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.


> 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?


> 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.


>
> 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.


>
> Cheers
> Dan
>
>
> On Thu, Oct 8, 2015 at 6:06 PM, William Burns <mudokonman at gmail.com>
> wrote:
> > I also like #3.  However I wonder if we want to expand it to include
> cache
> > removal/expiration in this new event as well.  This would simplify a user
> > listening for data being changed in only a given listener and it could be
> > clustered.
> >
> >  - Will
> >
> > On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarreño <galder at redhat.com>
> wrote:
> >>
> >> I think I'm leaning towards 3.
> >>
> >> I would favour 2 if all listeners were already in place for Functional
> >> API, since I think down the line we'd want to offer 3 map-like APIs:
> >> ConcurrentMap, JCache and Functional Map. Hence phasing out Cache as an
> >> end-user API... Since we're not there yet, I'd vote for option 3 below.
> >>
> >> Cheers,
> >> --
> >> Galder Zamarreño
> >> Infinispan, Red Hat
> >>
> >> > On 5 Oct 2015, at 07:34, Dan Berindei <dan.berindei at gmail.com> wrote:
> >> >
> >> > Hi guys
> >> >
> >> > We have two different listener types for cache entry creation
> >> > (@CacheEntryCreated) and modification (of an already-existing entry,
> >> > @CacheEntryModified). However, PutMapCommand and
> >> > PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
> >> > from loaders and/or remote nodes, so we sometimes notify the
> >> > @CacheEntryCreated listeners instead of the @CacheEntryModified
> >> > listeners.
> >> >
> >> > PutMapCommand has a "workaround" for this: it also notifies the
> >> > @CacheEntryModified listener, regardless of whether it found the entry
> >> > or not. I'd like to change this [1] and make PutMapCommand and
> >> > PutKeyValueCommand behave the same way.
> >> >
> >> > These are the options I'm considering:
> >> >
> >> > 1. Replicate the PutKeyValueCommand behaviour, and document that we
> >> > may sometimes notify the @CacheEntryCreated listener even though the
> >> > entry already exists.
> >> > It would be the simplest to implement (in fact I already have a
> >> > patch), but it doesn't feel right.
> >> >
> >> > 2. Always read the previous value from loaders and/or remote nodes
> >> > when a @CacheEntryCreated/Modified event listener is registered.
> >> > This would give us the correct behaviour, at the expense of
> performance.
> >> >
> >> > 3. Same as option 2, but also add a @CacheEntryWritten listener type,
> >> > which only receives the new value and is notified regardless of
> >> > whether the entry was created or modified.
> >> > This would give users a choice: if they don't care about the previous
> >> > value, the cache will be just as fast as usual, but if they need the
> >> > previous value, they need to accept a slowdown.
> >> >
> >> > 4. Add the @CacheEntryWritten listener type, but only notify these
> >> > listeners instead of the @CacheEntryCreated/Modified listeners for
> >> > cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
> >> > This is the option Galder chose for the functional API, but the
> >> > difference between write-only and read-write operations is a lot
> >> > clearer there, so I'm not convinced it's ok for the ConcurrentMap API.
> >> >
> >> >
> >> > Personally I would choose option 3, because it would be mostly
> >> > backwards-compatible: old code would only need to change if existing
> >> > listeners are slowing down the cache.
> >> >
> >> > Cheers
> >> > Dan
> >> >
> >> > [1] https://issues.jboss.org/browse/ISPN-5752
> >> > _______________________________________________
> >> > 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
> >
> >
> > _______________________________________________
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151009/24e55d2c/attachment.html