Technically that would work. If the lock token is a property then anyone could read it and thus unlock the document, not just the locking user. Does that fit with your requirements?
In a public or relatively 'untrusted' environment you can think of the lock token as being nanaged in the same way as a password. Attaching the lock token(s) that a user holds to a JCR session then allows the user to unlock the nodes to which the lock tokens refer. The question then is where are the lock tokens stored. If a publically visible place is OK then a node property would work. -----Original Message----- From: Michael Harris [mailto:[EMAIL PROTECTED] Sent: 20 August 2008 13:45 To: [email protected] Subject: Re: Releasing a non session scoped lock Since we want user based lock management, is it OK to put the lock token on the node that is locked, and then for unlock, if the userId on the session matches the userId in the lock, associate the token with the session and unlock? On Wed, Aug 20, 2008 at 8:02 AM, Connor, Brett (LNG-TWY) < [EMAIL PROTECTED]> wrote: > The application has to maintain the lock token, and associate it with > the new session at some later date to unlock the node. > > > -----Original Message----- > From: Michael Harris [mailto:[EMAIL PROTECTED] > Sent: 20 August 2008 12:47 > To: [email protected] > Subject: Re: Releasing a non session scoped lock > > I also meant to ask is there any way to automatically have new > sessions associated with any lock tokens associated with the user when > the session is created ? > > > On 8/20/08, Michael Harris <[EMAIL PROTECTED]> wrote: > > > > Right > > > > what I am wondering is what do you do if the application needs the > > lock to persist for long periods time, and possible between app > > server > restarts. > > Where does the token get stored? Can I put it on the file node as a > > property? > > > > > > On 8/20/08, Angela Schreiber <[EMAIL PROTECTED]> wrote: > >> > >> hi michael > >> > >> How does one release a non-session scoped lock? > >>> > >> > >> the Session that is the lock-holder (contains the token associated > >> with the lock) must call Node.unlock to release the lock. the owner > >> (userID) is for information purpose only. > >> > >> see also: > >> Node#unlock > >> Session#addLockToken > >> Session#removeLockToken > >> Session#getLockTokens > >> > >> for details please refer to section '8.4 Locking' of the > >> specification. > >> > >> kind regards > >> angela > >> > >> > >> > > > > > > -- > > --------------------- > > Michael Harris REED ELSEVIER (UK) LIMITED - Registered office - 1-3 STRAND, LONDON WC2N 5JR Registered in England - Company No. 02746621
