RE: possible bug in XALockManager jackrabbit 1.4

[Roland Porath <ro...@exari.com>]

> -----Original Message-----
> From: dpfister@day.com [mailto:dpfister@day.com] On Behalf Of Dominique
> Pfister
> Sent: Thursday, 31 January 2008 7:10 PM
> To: dev@jackrabbit.apache.org
> 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 <ro...@exari.com> 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!