RE: On pipelining

Multi-threading can be done for requests that come in over the
same connection; this seems valuable, especially if each of the
requests require computation or communication with other service
elements in the network.

For example, you could have a server with a request thread and
a response thread, where requests would spawn additional threads
to handle them if necessary (e.g., if the request was for a
CGI or non-local resource) and then queue the results for the
response thread.

#    I would suggest that the multi-threading be done at the connection
level,
# not at the request level.  That way you can be sure the requests are
handled in their
# proper order.  Multi-threading at the request level would require some
other mechanism
# to be sure that they are executed in the same order, defeating the purpose
of multi-
# threading.  At a minimum, you must return the responses in the same order
that you
# received them.  Again multi-threading the requests would require a
mechanism to
# ensure this order, minimizing the benefits of such multi-threading.

 #     Consider three requests that:
# 1. display a database item.
# 2. update that database item.
# 3. display the same database item.

# The intent here is to show the before and after views of the database
item. In a
# multi-threaded request server, if the requests execute in 1,3,2 order, or
2,1,3 order,
# the before/after sense of the display is lost.  Note that this is true
even if you force
# the order of responses to be reshuffled as 1,2,3.

#      So, I don't see how you can make it work if you multi-thread the
requests.

but

   Clients SHOULD NOT pipeline requests using non-idempotent methods or
   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
   premature termination of the transport connection could lead to
   indeterminate results. A client wishing to send a non-idempotent
   request SHOULD wait to send that request until it has received the
   response status for the previous request.

It is not the server's responsibility to insure consistency, and a server
implementation that multithreads the responses would seem to be valid.

Received on Friday, 21 January 2000 08:14:02 UTC