<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure about including removals/invalidations/expiration,<br></blockquote><div><br></div><div>Invalidations to me don't quite fit, since it should be passivated in that case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
because there would be no way to say "I want to be notified on<br>
creation and modification, but no removals". On the other hand, adding<br></blockquote><div><br></div><div>We could always add a parameter to the new annotation to say if you don't care about removals maybe?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3 more methods delegating to the same implementation, while not<br>
pretty, does allow you to listen to all changes.<br></blockquote><div><br></div><div>Do we need 3 methods? Yes I think it would be nice for people.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or are you thinking that the 3 additional listeners would add<br>
significant overhead when clustered?<br></blockquote><div><br></div><div>I was thinking it would be 1 listener. CacheNotifierImpl could raise the new event in addition to the existing ones.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers<br>
Dan<br>
<br>
<br>
On Thu, Oct 8, 2015 at 6:06 PM, William Burns <<a href="mailto:mudokonman@gmail.com" target="_blank">mudokonman@gmail.com</a>> wrote:<br>
> I also like #3. However I wonder if we want to expand it to include cache<br>
> removal/expiration in this new event as well. This would simplify a user<br>
> listening for data being changed in only a given listener and it could be<br>
> clustered.<br>
><br>
> - Will<br>
><br>
> On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarreño <<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>> wrote:<br>
>><br>
>> I think I'm leaning towards 3.<br>
>><br>
>> I would favour 2 if all listeners were already in place for Functional<br>
>> API, since I think down the line we'd want to offer 3 map-like APIs:<br>
>> ConcurrentMap, JCache and Functional Map. Hence phasing out Cache as an<br>
>> 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><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><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></div>