On Fri, Oct 9, 2015 at 4:39 PM, William Burns <mudokonman(a)gmail.com> wrote:
On Thu, Oct 8, 2015 at 12:39 PM Dan Berindei <dan.berindei(a)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