It is. But JBC doesn't know anything about that. As I think about the semantics of what Hibernate actually wants, not sure it wants a changing DataVersion at all. It has a DataVersion impl NonLockingDataVersion that never reports a version conflicts; that's what it uses by default. Only if it the underlying entity is versioned does it try to apply a real version to the node; there it wants to use the db version (which makes sense to me). Perhaps that can be dropped, and the non There's 3 kinds of writes to the cache in the Hibernate entity caching case: 1) Write to cache as part of tx that creates a DB record. 2) Write to cache as part of tx that updates a DB record. 3) Insertion into cache of data that's read from DB. #3 is the one that's most likely to result in trying to write stale data to the cache. But we already handle that by calling putForExternalRead, which will silently fail if the target node even exists. Version doesn't matter -- it just fails. Issue then is more about conflicts related to #1/#2; most simply two concurrent #2 cases. I'll have to think more about whether there is any benefit to storing the version in the JBC node there; i.e. whether any conflicts would already be caught at the db level before the cache write is even attempted. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133957#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...