Hi Roland, The lock holder is the JCR session currently holding the lock, allowed to perform changes on the node (and its descendants if the lock is deep). The only place in the source I see that actually sets the lock holder to null is Session.removeLockToken(). After this call, the node is still locked and no session is allowed to change the node (until it issues Session.addLockToken() of course), so the check looks ok to me. What do you think?
Kind regards Dominique On 30/01/2008, Roland Porath <[EMAIL PROTECTED]> wrote: > I've spotted some code in XALockManager.checkLock(NodeImpl node) that seems > somewhat dubious to me: > > > > if (info != null && info.getLockHolder() != node.getSession()) > > if this line evaluates to true a LockException is thrown > > > > it seems to be not unusual for info.getLockHolder() to be null so I've > changed that line to > > if (info != null && info.getLockHolder() != null && info.getLockHolder() > > > > > this obviously changes the locking/unlocking behavior. > > At this stage I do not understand the jackrabbit code or the jcr locking > philosophy very well so any feedback on my thoughts here will be greatly > appreciated > > > > Cheers > > > > roland > > > > > >
