> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dominique > Pfister > Sent: Thursday, 31 January 2008 7:10 PM > To: [email protected] > Subject: Re: possible bug in XALockManager jackrabbit 1.4 > > 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
Fair enough I reckon. My assumption was that no lock holder means no lock. Obviously I am still having a steep learning curve. Cheers roland > > 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 > > > > > > > > > > > > > > !DSPAM:47a1826747761292617819!
