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:[EMAIL PROTECTED] Sent: 18 April 2007 17:10 To: [email protected] 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. ( [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. > >
