Daniel John Debrunner wrote:
[EMAIL PROTECTED] wrote:
Currently, the Derby client contains a client-side implementation of
setQueryTimeout; using a TimerTask to invoke Statement.cancel() on the
client side. First of all, cancel() is not implemented, so this doesn't
work. Furthermore, we should use the server-side mechanism we now have
for statement timeouts.
For this, we need to transfer the timeout value from the client to the
server, preferable without a separate round-trip. I have some loose
thoughts on how to do this:
I'm not so sure, the reason is that the client side query timeout is
performing additional or different work. The client side needs to
timeout if the server has not responded within the given time, this
includes communication problems between the client and server.
So assume we have to fix the network communication problem, so the
client times out and cancels the statement if it has no received no
response from the server. Now if this is done, what is the advantage of
also pushing the timeout value to the server? You now have two timeouts
running, performing exactly the same operation. And most likely the
client one will fire first as it is set up first.
I would not say they perform exactly the same operation. The one on the
server side stops the processing, causing statement rollback. The one on
the client side just returns control to the application. I would think
the application would be interested in knowing the transaction state
after a statement timeout. Therefore, the server should time out the
statement and throw an exception to the client. Otherwise, it might be
that the statement successfully completes execution on the server side,
but is cancelled on the client side before the result is returned. In
this case, the client would get an exception, wrongfully indicating that
the statement processing was cancelled when it in fact was not. This may
result in erroneous client behaviour later, and thus, unexpected
inconsistencies in the database (at the application semantic level).
Alternatively, the client must use a different exception code on
timeout, implying that the outcome of the last statement execution is
unknown.
Also, cancelling a statement only on the client side leaves the server
processing the statement indefinitely. If your motivation for using
setQueryTimeout() is to prevent "runaway" queries, this will not achieve
what you want in client/server mode.
I agree that detecting and handling communication problems between the
client and server is necessary, but I don't think this is the
responsibility of the query timer. A connection failure should not only
terminate statements; the server will have to roll back uncommitted
transactions, and the client knows this. So we need to separate
connection failures from query timeouts.
In the spirit of making Derby behave the same in both embedded and
client/server mode (as far as possible - of course, connections may
fail), I think the server's querytimeout mechanism should be used
regardless of operating mode.
--
Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101
