RE: Streamability II

-------- Original Message --------
> From: Eric Prud'hommeaux <mailto:eric@w3.org>
> Date: 22 June 2004 15:16
> 
> On Tue, Jun 22, 2004 at 02:40:06PM +0100, Seaborne, Andy wrote:
> > 
> > 
> > Tom - you didn't explicitly say that the pages were held on disk at
> > any time - are they?  Just sometimes? 
> > 
> > Janne - While the server may be storing state in the server-side
> > ResultSet that is paged, this just a matter of how Tucana have chosen
> > to implement their system.  There does not appear to be in the
> > application-contract that means server state is necessary.  The
> > client-side ResultSet class is going over the results one at a time -
> > the fact that there is an implementation that has the client pulling
> > pages on demand is hidden.  The key is that the interface to the
> > application is result-by-result. 
> > 
> > The same thing could be achieved with protocol that just pumps
> > results as it can and let the network block if the client can't keep
> > up.  In this case, no server state is involved (outside the lifetime
> > of the query) in the query processor.  Might still choose in the
> > server to record result to disk sometimes (e.g. consistency in the
> > presence of updates). 
> > 
> > If it's a big set of results and the client can't keep up with the
> > server, then something somewhere has to block.  It may be in the
> > query result protocol; it may be in the TCP stack.  I prefer to keep
> > it in the TCP stack until we have a need otherwise for a web facing
> > system.  There is a Denial-Of-Service attack point in creating TCP
> > connections for operations then doing nothing with them but this is a
> > well known problem.  DAWG isn't making it any different - it's the
> > same as asking for large images and not reading them.
> 
> Doesn't that still leave the server locking tables or making a copy of
> them?

True for any consistency soltuion.

> 
> Server finds a zillion matches to a query.
> It could, before another thread starts, dump them out over the network.
> The TCP window goes to 0. The server has to just sit there locked, or
> copy the answers off so it can handle updates.

The TCP buffering and flow control is per-connection.  If the connection is
doing one request (HTTP) then it can't be doing anything else.   We aren't
multiplexing at that level.  Other TCP connections can be doing things and
will be uneffected.

> It seems like at that point, we'd rather have the flow control at a
> higher level so we could be cleverer about sharing state with the
> client. 
> I think anything that scrolls in arbitrary time makes this scenario
> more likely.

You are assuming that the client isn't doing anything to help.  JDBC
ResultSet cursors may be implemented purely client-side.

	Andy

Received on Tuesday, 22 June 2004 10:22:53 UTC