<div dir="ltr">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.<div><br></div><div> - Will</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarreño <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think I'm leaning towards 3.<br>
<br>
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.<br>
<br>
Cheers,<br>
--<br>
Galder Zamarreño<br>
Infinispan, Red Hat<br>
<br>
> On 5 Oct 2015, at 07:34, Dan Berindei <<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>> wrote:<br>
><br>
> Hi guys<br>
><br>
> We have two different listener types for cache entry creation<br>
> (@CacheEntryCreated) and modification (of an already-existing entry,<br>
> @CacheEntryModified). However, PutMapCommand and<br>
> PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value<br>
> from loaders and/or remote nodes, so we sometimes notify the<br>
> @CacheEntryCreated listeners instead of the @CacheEntryModified<br>
> listeners.<br>
><br>
> PutMapCommand has a "workaround" for this: it also notifies the<br>
> @CacheEntryModified listener, regardless of whether it found the entry<br>
> or not. I'd like to change this [1] and make PutMapCommand and<br>
> PutKeyValueCommand behave the same way.<br>
><br>
> These are the options I'm considering:<br>
><br>
> 1. Replicate the PutKeyValueCommand behaviour, and document that we<br>
> may sometimes notify the @CacheEntryCreated listener even though the<br>
> entry already exists.<br>
> It would be the simplest to implement (in fact I already have a<br>
> patch), but it doesn't feel right.<br>
><br>
> 2. Always read the previous value from loaders and/or remote nodes<br>
> when a @CacheEntryCreated/Modified event listener is registered.<br>
> This would give us the correct behaviour, at the expense of performance.<br>
><br>
> 3. Same as option 2, but also add a @CacheEntryWritten listener type,<br>
> which only receives the new value and is notified regardless of<br>
> whether the entry was created or modified.<br>
> This would give users a choice: if they don't care about the previous<br>
> value, the cache will be just as fast as usual, but if they need the<br>
> previous value, they need to accept a slowdown.<br>
><br>
> 4. Add the @CacheEntryWritten listener type, but only notify these<br>
> listeners instead of the @CacheEntryCreated/Modified listeners for<br>
> cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().<br>
> This is the option Galder chose for the functional API, but the<br>
> difference between write-only and read-write operations is a lot<br>
> clearer there, so I'm not convinced it's ok for the ConcurrentMap API.<br>
><br>
><br>
> Personally I would choose option 3, because it would be mostly<br>
> backwards-compatible: old code would only need to change if existing<br>
> listeners are slowing down the cache.<br>
><br>
> Cheers<br>
> Dan<br>
><br>
> [1] <a href="https://issues.jboss.org/browse/ISPN-5752" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/ISPN-5752</a><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div>