Well, no luck. I replaced OptimisticTreeCache with the latest version from CVS, which, as I understood from reading HHH-1796 at least, should fix the problem using a new Fqn. I've been debugging and browsing code for hours now trying to figure out what is going on and I think problem is twofold, and both are related. It seems at some point instances of org.jboss.cache.optimistic.WorkspaceNodeImpl, which by default appear to have their version set to DefaultDataVersion.ZERO, are altered via a call setVersion() with null as an argument. 1/ Now the first part of the problem seems exactly what you mention, i.e. "no way Hibernate would apply a DataVersion to a query cache thus we set null". But looking at these lines from org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.createNode(): DataVersion version = null; | if (ctx.getOptionOverrides() != null && ctx.getOptionOverrides().getDataVersion() != null) | { | version = ctx.getOptionOverrides().getDataVersion(); | workspace.setVersioningImplicit( false ); | } it seems the transaction workspace's versioning mode is set to explicit versioning when we pass in an Option which sets a DataVersion, for example when calling OptimisticTreeCache.writeLoad(). But then, somewhat further in the same method, we have: if (!workspace.isVersioningImplicit()) childWorkspaceNode.setVersion(version); If now this method gets called again by Hibernate's StandardQueryCache for example, via OptimisticTreeCache.put(), then the workspace versioningImplicit still remains false. Since a put call like this one doesn't contain a set dataversion, the above method call will effectively reset the default DefaultDataVersion.ZERO of org.jboss.cache.optimistic.WorkspaceNodeImpl to null. Since I do not have intimate knowledge of the JBoss and Hibernate code, I may be totally wrong, but adding the line below to OptimisticTreeCache.put() sure does fix the problem. This might not be the ideal fix since I assumed only StandardQueryCache directly calls OptimisticTreeCache.put(): option.setDataVersion(DefaultDataVersion.ZERO); 2/ The second part of the problem seems similar, but it appears to be caused by a call to writeLoad() where source==null. This also ultimately boils down to passing in an Option with a dataversion null. In the stack this happens when loading a one to many collection. But I'm still trying to find out what is happening there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957096#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...