db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oyvind.Bakk...@Sun.COM
Subject Re: Statement.setQueryTimeout() in client/server mode
Date Tue, 26 Jul 2005 14:01:07 GMT
Daniel John Debrunner wrote:
> Oyvind.Bakksjo@Sun.COM 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

Mime
View raw message