[infinispan-dev] Cache entry creation and modification events

[Dan Berindei]

On Mon, Nov 2, 2015 at 12:29 PM, Galder Zamarreño <galder at redhat.com> wrote:
>
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 20 Oct 2015, at 15:05, Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> On Mon, Oct 19, 2015 at 5:34 PM, Galder Zamarreño <galder at redhat.com> wrote:
>>>
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 14 Oct 2015, at 16:43, Dan Berindei <dan.berindei at gmail.com> wrote:
>>>>
>>>> There is one more thing to consider: the interface for acting on the
>>>> previous value of an event is very clunky even today. It basically
>>>> requires a thread-local to keep track of the previous value from the
>>>> pre=true invocation to the pre=false invocation, and even that won't
>>>> work once the reactive interceptor stack lands (so that pre and post
>>>> events are triggered on different threads).
>>>>
>>>> So I'm starting to think we should go with option 1 for now, and start
>>>> a bigger redesign of the cache notifications for 9.0:
>>>> * Remove the pre=true events
>>>> * Add explicit event properties for the previous value/metadata
>>>
>>> Why redesign cache notifications? As I mentioned in a previous reply, I see Cache and cache notifications being phased out in favour of: JCache (and its events), ConcurrentMap and Functional Map (and its events) :|.
>>
>> How is the ConcurrentMap API different from the Cache API?
>
> Cache is ConcurrentMap + a mixed bag of other things which includes all sorts of things, from put operations that take extra parameters, to ways to retrieve the Batch container :|
>
> ConcurrentMap is what is given to use by the JDK whereas the rest of Cache API is what we want to have, or legacy stuff we've had since day 1.
>
> Where possible, we should promote users to use standard APIs, so that's ConcurrentMap (as-is, no Cache) and JCache. If the users find limitations on those, we should try to fill those gaps with Functional Map.
>
> It's true that today, using ConcurrentMap is done by getting a Cache, which IMO is really confusing in how we expose our APIs. So, yeah, if people want to use ConcurrentMap, they need Cache, but that should not be the case.
>

I always thought by ConcurrentMap you meant our current API, because
it's ConcurrentMap-based. I don't think we ever adviced users to get a
cache instance and cast it to ConcurrentMap...

If we want to deprecate the Cache interface in 9.0, then we can forget
about evolving its notification API, but I figured we'd want to keep
it for stuff that's not covered by the standard. E.g. JCache forces us
to fetch and deserialize the previous value for listeners, even if
they might only need the key; our notification API could allow the
listener to declare if it needs the value or not.

>>
>>>
>>> So, no need to redesign Cache notifications IMO :|
>>
>> I was assuming JCache listeners are implemented on top of the Cache
>> listeners, so they would need fixes in the Cache listeners to work
>> properly.
>
> ^ Yeah, currently that is the case.

Do you have plans to change that for 9.0?

>
>> We could implement the JCache listeners directly in 9.0 and remove the
>> Cache listeners, I guess. But looking at the JCache API it looks like
>> their listeners need the previous value for all writes, unlike the
>> FunctionalMap listeners, so I think there will still be a need for a
>> lower-level implementation.
>
> Depends. JCache API impl could decide, based on whether any listeners are attached, whether those write-only operations should become read-write operations because listeners attach demand it, as opposed for the actual function requiring to read previous value.

I would very much like to skip reading the previous value when it's
not needed by the command and/or listeners, but I think that logic
should be common to all APIs. There will definitely be applications
using both the FunctionalMap's write-only operations and JCache
listeners on the same underlying cache instance...

Cheers
Dan