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

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev