Subject: What is left after LOCK/UNLOCK on null resource?

From: "Michael Leditschke" <[email-masked]>
Date: Wed, 4 Sep 2002 13:26:57 +1000

I'm doing some experimenting with
Tomcat 4.0.4+Slide1.0.16+IE6 on WIN2K box.

I would appreciate some advice as to the 
expected behaviour in the following scenario:

1. A null resource is locked.

Q. Should this resource appear as a member
URI of its parent? 

IE displays the lock-null
resource as a directory, which doesn't seem right.

2. The null resource is unlocked.

Q. Should there be anything left if no other 
command is issued in between?

Looking at the Slide database, there continues to 
be information maintained about the unlocked 
resource. I would have thought everything should have
been cleaned out, i.e. the properties created for the
locked resource should have been deleted.

IE also continues to show the now unlocked resource as
a directory, but it doesn't act as a collection, e.g. 
you can't create members within it. I suspect this is as
a result of the Slide behaviour.

Any clarifications greatly appreciated.

Regards
Michael

--

Michael Leditschke
AMMD Professional Services Pty Ltd
+61 407 671 480

"The question of whether computers can think is 
like the question of whether submarines can swim"
 
                    --Edsger W. Dijkstra,         
                      deceased 6 August 2002

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 5 Sep 2002 14:03:24 -0400

Just to avoid any misunderstanding, using the DeltaV protocol
will only allow such interoperation if we get clients and servers
to support the protocol.  Probably I should have said
"would theoretically allow" instead of "would effectively allow" (:-),
but that is one reason I encourage folks to use the DeltaV protocol
in their clients and servers if they want to provide shared long-term
locking functionality.

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]

My point about using the DeltaV protocol for "long-lived locking"
(or "shared locking) applications was that using this protocol
would allow a client to effectively interoperate with a wider
variety of servers (both versioning and non-versioning), with the
"version URL" effectively replacing the functionality of the
"shared lock token".