On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei(a)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(a)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(a)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(a)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(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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev