RE: Proposal for LOCK & UNLOCK
Jim, LOCK/UNLOCK is the equivalent of GRABSERVER/UNGRABSERVER. I would
actually prefer to just introduce BEGINTRANSACTION/ENDTRANSACTION but
that brings us into an even deeper pit that everyone has agreed we
> -----Original Message-----
> From: firstname.lastname@example.org [SMTP:email@example.com]
> Sent: Friday, March 21, 1997 8:07 AM
> To: Yaron Goland
> Cc: firstname.lastname@example.org
> Subject: Re: Proposal for LOCK & UNLOCK
> I've been watching the WebDav list at a low level, so
> take this suggestion with the appropriate size block of salt...
> Another way to enforce atomicity (crude, but often effective), is the
> way we dealt with this problem in the X Window System protocol, where
> atomicity problems came up in window management operations.
> We basically defined a critical section, by saying:
> This, for a client using a persistent connection and streaming
> (which was, of course, the normal behavior for the X protocol, and now
> for HTTP/1.1), allowed a well written client to batch the set of
> requests that needed to be atomically completed without introducting
> complicated locking of resources into the entire X Window System
> Clients that needed this ability (typically window managers), buffered
> the requests that needed atomicity, and then transmitted the entire
> at once; the server then processes them as fast as possible, and
> the server.
> I would suggest (with the addition of a timeout) this might be a
> way to go than having full blown locking of resources everywhere, and
> into HTTP/1.1 easily. The closing of a connection can also do an
> So FWIW, here is a KISS approach to the problem that was effective in
> system, in case you think it useful.
> - Jim Gettys