[infinispan-dev] Cache entry creation and modification events

[William Burns]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20151008/6ca339e0/attachment-0001.html