[infinispan-dev] Cache entry creation and modification events

[Dan Berindei]

I'm not sure about including removals/invalidations/expiration,
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
3 more methods delegating to the same implementation, while not
pretty, does allow you to listen to all changes.

Or are you thinking that the 3 additional listeners would add
significant overhead when clustered?

Cheers
Dan


On Thu, Oct 8, 2015 at 6:06 PM, William Burns <mudokonman at 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 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
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev