[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem

[floefliep]

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