You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Shaun Barriball <sb...@yahoo.co.uk> on 2007/04/18 17:47:40 UTC
Locking a node does not prevent it from being deleted or moved?
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 intentional?
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.
Re: Locking a node does not prevent it from being deleted or moved?
Posted by David Nuescheler <da...@gmail.com>.
ohh... one more thing ;) :
If your application wants to find out if another session or application
has an active lock below a certain node before removing,
I would recommend to try to acquire a "deep" lock on the node
to be removed.
regards,
david
Re: Locking a node does not prevent it from being deleted or moved?
Posted by Julian Reschke <ju...@gmx.de>.
David Nuescheler schrieb:
> 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 )
...that would make locking more compatible with WebDAV locking.
Best regards, Julian
RE: Locking a node does not prevent it from being deleted or moved?
Posted by Shaun Barriball <sb...@yahoo.co.uk>.
Thanks David.
We'll use the deep lock facility at the moment as a prereq for deletion and
move.
If after this we feel its still strange behaviour then I'll log a ticket.
Your feedback is appreciated.
Regards,
Shaun.
-----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 )
regards,
david
On 4/18/07, Shaun Barriball <sb...@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
intentional?
>
> 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.
>
>
Re: Locking a node does not prevent it from being deleted or moved?
Posted by David Nuescheler <da...@gmail.com>.
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 )
regards,
david
On 4/18/07, Shaun Barriball <sb...@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 intentional?
>
> 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.
>
>