Guys,
Can anyone help me here? How does one get the lockToken's value in a
client? Th elockdiscovery seems to return
opaquelocktoken:dummytoken rather than the actual token :-(
There has been huge discussin here but no answer???
Any replies will be appreciated..
Uma
-----
It is very reasonable/sensible behavior for a client to
refuse to unlock a resource if it wasn't the process that
took out the lock. A client should never unlock such
a resource without getting explicit confirmation from the
user to do so, but a client can reasonably refuse to give
the user that choice, because a user is often not in a
position to make the right choice (i.e. forgets or is not
aware that something else being done on their behalf requires
that resource to be locked).
Such a client should of course set a timeout on any lock that
it takes out, so that the server can automatically expire a
lock when the client that took out the lock has dies or otherwise
failed to unlock.
Cheers,
Geoff
-----Original Message-----
From: Michael Leditschke [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]:%20What%20is%20left%20after%20LOCK/U
NLOCK%20on%20null%20resource?&In-Reply-To=%3c3906C56A7BD1F54593344C05BD1
[EMAIL PROTECTED]&References=%3c3906C56A7BD1F54593344C05BD137
[EMAIL PROTECTED]> ]
... It would appear
that the slide client can only delete a lock if it created
the lock in the *same* session. If I fire up the client,
create a lock, exit, fire it up again and attempt an unlock,
the operation fails. Nothing appears on the wire. A brief
troll through the code suggests the client won't even try if
it doesn't find the lock in its internal state structure, and
this structure only gets populated as part of a lock operation
- though I'm happy to be corrected.
Can anyone confirm whether this is the expected client behaviour,
or a bug? I would have thought you should be able to unlock a
resource independent of when the lock operation occurred.
