Re: [jbosscache-dev] Issue with JBCACHE-1309 WAS: Branch for 2.1.X

> < SNIP /> > >>> ...... >>> org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:488) >>> What's going on here is fetchWorkspaceNode() is walking up the tree >>> from /TS/test/org/hibernate/cache/UpdateTimestampsCache/Accounts to >>> Fqn.ROOT, calling lockAndCreateWorkspaceNode() on each Fqn. When it >>> gets to Fqn.ROOT it fails. This is because >>> lockAndCreateWorkspaceNode() wants a write lock on the target node >>> before making the workspace copy. In this case the WL can't be >>> obtained, because a RL is held by the suspended tx. >>> Does lockAndCreateWorkspaceNode() need a write lock here? > > Probably not. I'm guessing it could do with a RL instead, let me > investigate. Ok, this is only called when a node exists in the tree and it needs to be added to the workspace. In this case, we should only attempt to acquire a read lock, not a write lock. The write locks are acquired on nodes marked as dirty when a transaction commits. This fix is in svn (trunk and 2.1.X) and your tests - along with other optimistic locking tests - pass. I'm waiting for a full Hudson test suite run.