Option.setCacheModeLocal(true) is definitely enough to ensure non-propagation of the remove call. Getting into an inconsistent state is for sure a sign of a bug/greater problem. Greater problem might just be don't use async, but let's dig deeper. Can you make this happen with INVALIDATION_SYNC? ASYNC by its nature doesn't guarantee cache consistency, although ending up with an earlier version on a node and no JBC exception in the logs doesn't sound right. With INVALIDATION, the only thing that puts data in the cache is the local caller, so having version 39 in the cache means a local caller either 1) put it in the cache after the invalidation message for 40 had already arrived 2) the invalidation message for 40 never arrived. The latter is unlikely. Do you have any logging telling you how version 39 ended up in A? What it via a putFromExternalRead or a put after a tx running on A updated the entity to version 39? This smells more like a putForExternalRead problem to me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221589#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...