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#3957096
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957096
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
