[jbosscache-dev] Issue with JBCACHE-1309 WAS: Branch for 2.1.X
Manik Surtani
manik at jboss.org
Thu Apr 3 11:17:17 EDT 2008
On 2 Apr 2008, at 16:20, Brian Stansberry wrote:
> Manik Surtani wrote:
>
>>> < 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.
>
> Excellent; thanks for the quick turn. If all looks well can you
> deploy another 2.1.1-SNAPSHOT?. I'll rerun the Hibernate tests with
> it.
Done.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org
More information about the jbosscache-dev
mailing list