[infinispan-dev] Cache entry creation and modification events

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