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.
( [EMAIL PROTECTED] )
regards,
david
On 4/18/07, Shaun Barriball <[EMAIL PROTECTED]> 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.
