[infinispan-dev] Cache entry creation and modification events

[Dan Berindei]

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