The discussion on a javagroups-development thread made me realize that for sure JBC wants to take advantage of the 2.6 connect+statetransfer feature. The JBCACHE-315 solution is only really applicable to a FLUSH associated with a state transfer. That's when the cache needs to ensure the state it transfer doesn't have any changes in it from uncommitted transactions. Since the JBCACHE-315 fix is potentially disruptive to transactions, we want to use it as judiciously as possible. Combining connect+statetransfer is a good step in that direction. Beyond that: 1) A block() call associated with a simple connect. JBC has no need to deal with ongoing transactions; just prevent messages going out. 2) A block() call associated with a state transfer request for a different state-id. For example, two different caches sharing a multiplexed channel; cacheA gets a block call when a new instance of cacheB deploys somewhere. Again, cacheA has no need to deal with ongoing transactions since it won't be transferring staet; just prevent messages going out. Problem is JBC has no idea what the context is when its block() callback is invoked. Brian Stansberry wrote: -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com