[infinispan-dev] Cache entry creation and modification events

[Dan Berindei]

On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman at gmail.com> wrote:
>
>
> On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei at gmail.com> wrote:
>>
>> I'm not sure about including removals/invalidations/expiration,
>
>
> Invalidations to me don't quite fit, since it should be passivated in that
> case.

Passivations have a different listener, I didn't include
@CacheEntryPassivated here :)

Perhaps invalidation doesn't fit, because it's used to remove stale
entries either after a rebalance, or after a write (for L1 entries, or
in invalidation mode).

But then I would say expiration also doesn't fit, because the all the
others are direct actions by the user, and expiration happens in the
background.

>
>>
>> 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
>
>
> We could always add a parameter to the new annotation to say if you don't
> care about removals maybe?

Yes, that should work.

>
>>
>> 3 more methods delegating to the same implementation, while not
>> pretty, does allow you to listen to all changes.
>
>
> Do we need 3 methods?  Yes I think it would be nice for people.

I'm assuming the listener methods are checked to receive the right
event types. If we allow supertypes (and make CacheEntryWrittenEvent a
supertype of the others) it could be just 1 method with 4 annotations.

>
>>
>>
>> Or are you thinking that the 3 additional listeners would add
>> significant overhead when clustered?
>
>
> I was thinking it would be 1 listener.  CacheNotifierImpl could raise the
> new event in addition to the existing ones.

Right, if we include the removals in this annotation there would be
just one listener. But would it be faster than having 4 listeners, one
for create/update, and one each for remove/invalidation/expiration?

Cheers
Dan