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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052664#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...