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

[Manik Surtani]

On 1 Apr 2008, at 22:58, Manik Surtani wrote:
> On 1 Apr 2008, at 21:53, Brian Stansberry wrote:
>> Test for this is  
>> org 
>> .jboss 
>> .cache 
>> .integration 
>> .hibernate 
>> .UpdateTimestampsCachingTest 
>> .testTimestampUpdateInAfterCompletionOptimistic()
>
> Could you add this test to trunk a well?
>
>> Brian Stansberry 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.

Cheers
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org