[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