[infinispan-dev] Cache entry creation and modification events

[Galder Zamarreño]

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