Re: Proposal: WebDAV and transactions

>>> In the spirit of that analogy, I
>>> am proposing that the entire transaction, conditional processing and 
>>> all,
>>> should be invoked by one method call. That would do a lot to help 
>>> protect
>>> the performance of the system.
>
> It would do nothing to help protect the performance of the system.
> There is no effective difference between a sequence of requests with
> time-outs per request and a batch request with time-outs per read.
> The server still has to accumulate requests in storage and is
> subject to the same service problems with stateful behavior.
>
> ...snip...
>
> ....Roy
>
> That's completely false.

I suggest you learn how to write an HTTP server before making statements
like that.

> Last first. The only way to eliminate state on the server that must be
> maintained between method calls ("stateful behavior") is to do the entire
> transaction during one method call. Period.

That's specious.  The only difference between one method containing many
requests and one connection containing many methods is syntax and
the number of server responses on that connection.  In one case you
are building state because of HTTP methods and the other because of
XML methods.  The server responses are not in the critical path and
therefore do not impact performance other than giving the client
important information that might be useful to determining whether
it should abort the transaction.

> Going over the network multiple times for multiple method calls clearly
> consumes more computing resources and elapsed time than making a single
> method call. There is more overhead on the client (which doesn't matter) 
> and
> the server (which matters a lot). That's really obvious.

Pipelined requests make the difference irrelevant.  The overhead of
parsing XML far exceeds the overhead imposed by parsing multiple HTTP
requests.  And, yes, non-idempotent methods can be pipelined if they
are sent as part of the context of a transaction, since building a
transaction context is inherently safe.

> But where client application programmers can really kill the performance 
> of
> the entire system is by introducing the possibility of user think time 
> into
> the middle of a transaction. That is only possible when the transaction 
> can
> consist of multiple method calls.

Unless you have time-outs on the transaction, which is true of any
performance limited system.  The protocol represents a wire syntax.
If you think that merely packaging multiple requests into a single
request method will force clients to send all requests at once, then
you seriously underestimate the creativity of HTTP client developers.
At least with multiple methods the server has a chance to respond
appropriately in the middle of the stream of requests, rather than
having to special-case the in-body request timeout handler.

> Between the method calls, the resources changed have to be locked on the
> server.

That's not how I described transactions.  I said that the requests are
collected on the server and only applied when the commit message is
received.  If the state has changed such that the methods are no longer
applicable, then the method transaction will fail on commit.

....Roy

Received on Thursday, 12 September 2002 10:03:00 UTC