CacheListener callbacks for block/unblock

[brian.stansberry]

More stuff that's too late for the 2.0 API...

This is morning shower thinking, so not very fleshed out.

What do people think about adding CacheListener callbacks related to block/unblock events? Vladimir has done some stuff related to state transfer handling to prevent calls proceeding into the cache during block, wait for in progress txs to complete or roll them back if they take too long etc. But it seems like the app would have a better idea of how to do that, with Vladimir's stuff a 2nd line of defense. For example, if the http session repl layer knew the cache was blocking, it could prevent calls into the cache and would have a better idea of how to deal with any tx rollbacks.

[manik]

Hmm, this is very specialised use of the listener. Not 'normal' usage, IMO ...

[brian.stansberry]

Yeah, I agree it's not normal. My only concern here is you can't really add it later. CacheListener is an interface people actually implement themselves, so "an added method isn't an API change" thinking breaks down.

I need to think quite a bit about whether/how I could use such callbacks to get a benefit beyond what Vladimir's done. My "shower thinking" a couple days ago had some ideas, but they don't seem so coherent as I've thought about it today.

If it turns out there is a good use for them, I could always of course have the AS do tricks (e.g. a CacheImpl subclass) to get notifications. Ugly, but not the end of the world.

In general, this thinking arises out of a concern that the multiplexer is going to lead to more frequent block calls for the JBC instances in the AS. The caches all share a channel, so one app doing a state transfer on a redeploy will cause a block on all caches. So, I'm noodling about strategies to minimize the impact of that.

[Semi-OT] One thing I'll have to have a look at is whether the blocking stuff Vladimir did discriminates between txs that have done a write and those that haven't. Unless cache is SERIALIZABLE, there's no reason to prevent reads or to rollback txs that have only done reads. Similar thinking applies to OPTIMISTIC -- since the tx workspace is not included in any state transfer, there is no reason to worry about any optimistic calls except the prepare.

[jason.greene]

Yeah, I agree it's not normal. My only concern here is you can't really add it later. CacheListener is an interface people actually implement themselves, so "an added method isn't an API change" thinking breaks down.

Right instead you have to introduce a new interface (ExtendedCacheListner or BlockCacheListener).

One thing I was toying with in POJO Cache, that I might introduce at a later date is an annotation driven listener, which is more flexible and extensible:

@AttachNotificationListener
@DetachNotificationListener
@ListModifyNotificationListener
public myMethod(Notification notification)
{
....
}

or they could do (both would work)

@AttachNotificationListener
public void myMethod(AttachNotification notification)
{
....
}

@DetachNotificationListener
public void myMethod(DetachNotification notification)
{
....
}

-Jason

[brian.stansberry]

Yeah, I like the annotation approach.

In 1.x we have ExtendedTreeCacheListener for just this sort of reason. :)

[manik]

The problem with adding block calls to the listener are that it is a specialised callback that serves little general purpose use.

The problem with a sub-interface is that it adds complexity and a performance bottleneck to the notifier (the need to test each listener if it is a subclass instance, etc).

If at all I'd prefer the 2nd approach, so we could even move viewChanged() to the 2nd interface - perhaps ReplicatedCacheListener with viewChange() and block/unblock events.

Thoughts?