jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaun Barriball" <sbarr...@yahoo.co.uk>
Subject RE: Locking a node does not prevent it from being deleted or moved?
Date Wed, 18 Apr 2007 16:14:24 GMT
Thanks David.
We'll use the deep lock facility at the moment as a prereq for deletion and
If after this we feel its still strange behaviour then I'll log a ticket.
Your feedback is appreciated.

-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com] 
Sent: 18 April 2007 17:10
To: users@jackrabbit.apache.org
Subject: Re: Locking a node does not prevent it from being deleted or moved?

Hi Shaun,

I agree that the behavior is slightly surprising.

It is according to the specification though, see section
8.4.8 Effect of a Lock / page 281
"Removing a node is considered an alteration of its parent. This means that
a locked node may be removed by any user with sufficient access permissions
as long as its parent node is not locked. "

I agree that this may be counter intuitive and I would recommend that you
file a comment in the upcoming Public Review of JSR-283 if you think that
the Expert Group should revisit its earlier rationale.
( jsr-283-comments@jcp.org )


On 4/18/07, Shaun Barriball <sbarriba@yahoo.co.uk> wrote:
> Hi all,
> While testing an application with JackRabbit we've noticed that 
> locking a node does not prevent it from being deleted or moved. Is this
> The use case is given a node hierarchy:
> A
> --B
>   --C1
>   --C2
> 1) Login as two separate users, X and Y
> 2) User X locks C1
> 3) User Y attempts to delete B as follows...
>     B.remove()
>     A.save()
> then the node will be deleted despite User X having a lock
> 4) If User Y attempts to delete B as follows then a LockException will 
> be thrown...
>    // locking with deep flag set to true which attempts to lock the 
> whole subtree
>    B.lock(true, false)  // throws exception so following lines not 
> executed...
>    B.remove()
>    A.save()
> 5) All of the above applies whether the delete/move is attempted on 
> the locked node itself or an ancestor.
> This is slightly surprising and has some worrying implications for 
> multi-user applications. All comments welcome.
> Regards,
> Shaun.

View raw message