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
should avoid.
	Yaron

> -----Original Message-----
> From:	jg@pa.dec.com [SMTP:jg@pa.dec.com]
> Sent:	Friday, March 21, 1997 8:07 AM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.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:
> 
> GRABSERVER
> REQUEST1
> REQUEST2
> REQUEST3
> ...
> REQUESTN
> UNGRABSERVER
> 
> 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
> protocol.
> Clients that needed this ability (typically window managers), buffered
> the requests that needed atomicity, and then transmitted the entire
> sequence
> at once; the server then processes them as fast as possible, and
> ungrabs
> the server.
> 
> I would suggest (with the addition of a timeout) this might be a
> simpler 
> way to go than having full blown locking of resources everywhere, and
> fits
> into HTTP/1.1 easily.  The closing of a connection can also do an
> implicit
> UNGRABSERVER.
> 
> So FWIW, here is a KISS approach to the problem that was effective in
> another
> system, in case you think it useful.
> 			- Jim Gettys

Received on Friday, 21 March 1997 15:09:28 UTC