(Apologies in advance; I'm relying on recollection a lot in this post as the JBC refactor has erased my old knowledge of how to quickly verify how things work. Going to take some time to rebuild.) Let me modify your use case a bit to reflect what actually happens: 6. Server 2 uses putForExternalRead to put V1 in cache, which with invalidation causes no cluster-wide traffic In this case, from a simplistic point of view one of two things will happen on Server 2 in step 6: a) the PFER arrives first, adds a node, and then the invalidation message invalidates it. This is fine. b) the invalidation message from Server 1 arrives first, so the PFER call sees an existing (tombstone) node and immediately returns. IIRC, the tombstone has a limited life so some later PFER can succeed; i.e. there is no need for the PFER to analyze the tombstone's data version to see if it's allowed to resurrect it. So this seems fine. I'm saying simplistic here because I'm assuming all the locking impls enforce the PFER semantic of never overwriting an existing node. If we convert your case to use replication instead of invalidation, all remains the same except step 5 is a replication message and 6. Server 2 uses putForExternalRead to put V1 in cache, which generates a cluster-wide PFER: In this case: a) on Server 2 the PFER arrives first, adds a node, and then the replicated update message overwrites it. This is fine. With respect to the replicated PFER message on other nodes, either: i) the PFER arrives first, and then the replicated update overwrites it ii) the replicated update arrives first and the replicated PFER sees the existing node and aborts. b) on Server 2 the replicated update message arrives first so the PFER sees an existing node and aborts. That all seems fine as well. I think the "abort if node exists" design of PFER serves us well here. Probably we need to think more about conflicts between updates rather than between PFER. Although in that case I would expect one or the other tx to fail before the JBC synchronization's beforeCompletion call. Bottom line, I'm slooooowly moving toward thinking this DataVersion stuff is not needed for the Hibernate case. And fully expect to be proven wrong. :-) If having DataVersion isn't seriously perturbing the code base, I recommend leaving it in with a JIRA to remove it before 3.0.0.CR1/late beta. That serves notice to the community that it might go while giving us time to think long and hard about it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163896#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...