Re: resourcetype locknull

   From: jamsden@us.ibm.com

   Lock-null resources were introduced to allow a user to "reserve" a
   name in the namespace. That is, to sort of create the resource and
   lock it in a single method. Otherwise, there is a race condition
   between the time the resource is created and the time it is locked
   where some other user could get the lock or otherwise change the new
   resource.

Isn't this functionally equivalent to someone getting the lock on the
lock null resource between the time when you issued the lock request
and the time it was handled by the server?  The fact that they got the
lock on the empty dummy resource you created, as opposed to a lock on a
"lock null" resource doesn't seem to change the situation in any
substantive way.

(Jim: Since you don't like lock null resources anyway, you shouldn't
feel compelled to answer this ... this question is intended for
anyone who *is* in favor of lock null resources :-)

   Lock-null resources represent an attempt to special case
   situations that arise from the need to have transaction semantics and
   stateful servers for distributed authoring. There are other cases (in
   the versioning spec too) where methods are overloaded with headers
   (control couples) to make them do something that could have been done
   with a number of other methods, but not atomically. There's also the
   argument of reducing round trips, but this is pretty limited in this
   case. HTTP can execute a lot of methods in a second, and authoring
   environments often have much lighter nonfunctional requirements that
   production server systems.

Yup, to all Jim says here.

   It was a real pain to implement lock-null resources as it is full of
   special cases. I too would just as soon see it removed from the
   spec. It doesn't seem that the complexity it adds to the protocol is
   consistent with the potential problem it solves.

   But Geoff, how do you reall feel about lock-null resources?

Oh, still pretty ambivalent ... (not :-).

Cheers,
Geoff

Received on Wednesday, 13 October 1999 15:47:55 UTC