[jbosscache-dev] LockParentForChildInsertRemove and PessimisticLocking

[Manik Surtani]

On 4 Aug 2009, at 21:28, Brian Stansberry wrote:

> Continuing dialogue with myself. :)
>
> I've found the logic in PessimisticNodeBasedLockManager where the
> LockParentForChildInsertRemove configuration is meant to be coming
> through via the Node.

Yes, this is because you can override this on a per-node basis.

> In our testing we're seeing cases where write
> locks are being acquired on parent nodes, which isn't the intent. I'll
> dig further.
>
> Brian Stansberry wrote:
>> https://jira.jboss.org/jira/browse/JBCACHE-1527
>>
>> Brian Stansberry wrote:
>>> From looking at the JBC 3 code, it seems the
>>> LockParentForChildInsertRemove configuration is no longer  
>>> respected for
>>> pessimistic locking.  I can't trace any path from the property in
>>> Configuration to code that uses it.
>>> PessimisticLockInterceptor.handlePutCommand, handleMoveCommand and
>>> handleRemoveNodeCommand all always tell the lock manager to lock
>>> parents. handleEvictFqnCommand always tells the lock manager not  
>>> to lock
>>> parents.
>>>
>>> This is causing failures in buddy replication testing when nodes
>>> join/leave clusters under load. There's a lot of data gravitation  
>>> plus
>>> stuff like migrating defunct backup trees to "DEAD" regions. Too  
>>> much
>>> contention for parent level locks.
>>>
>>> Plus locking on the structural parent to add/remove session nodes  
>>> will
>>> suck for the session caching use case.
>>>
>>
>>
>
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org