db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Statement.setQueryTimeout() in client/server mode
Date Fri, 01 Jul 2005 18:30:39 GMT
This would only support setQueryTimeout() mechanism, but not the
cancel(), right? Wouldn't having support for cancel() be useful too, if
applications like to cancel a long running query? (that didn't have
timeout set) Also, I wonder if the protocol has support for cancel
mechanism.... If so, using that could be used by all other clients too?
(like any possible future ODBC implementations?)


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:
> * If the client has set a timeout value for a statement, prepend the
> (DRDA) EXCSQLSTT command with an EXCSQLSET command which contains the
> timeout value; e.g., "SET STATEMENT TIMEOUT 10" (the actual wording is
> not important for this general discussion).
> * In DRDAConnThread.parseEXCSQLSETobjects() on the server side,
> recognize the "SET STATEMENT TIMEOUT" text, parse the timeout value
> and remember it for the coming EXCSQLSTT command. Do NOT invoke
> executeUpdate() with the SET statement [see note below].
> * In DRDAConnThread.parseEXCSQLSTT(), check if a timeout value has
> been set; if so, use it (by setting the timeout value on the
> server-side Statement object before calling execute/executeQuery).
> Note: Instead of having the "SET STATEMENT TIMEOUT" syntax be
> understood only by the Network Server, we could augment the Derby SQL
> grammar with such a vendor-specific feature. In that case, I think the
> timeout value should be considered session-wide; meaning, affecting
> all succeeding statements on the same connection, with the same value,
> until modified. This would support timeouts in SQL clients like ij.
> But this is not the important part.
> When going into details, we'll also need to consider the behaviour
> with batched statements and prepared versus unprepared statements
> (different DRDA commands are being sent from client to server), but at
> this early stage I would just like to get some feedback on these
> general ideas.

View raw message