db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
Date Mon, 10 Oct 2005 17:34:49 GMT
    [ http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12331730 ] 

Kathey Marsden commented on DERBY-506:

My experience with  client side code that has tried to do this in past is that it has historically
caused trouble.    Common issues with this approach.

1) The error messages don't make sense because they are delayed.  The embedded call to the
corresponding client method  happens when the statement is executed and any related exception
will happen at that  time.   Not really in keeping with JDBC, embedded compatibility or user

2)  The client has to have a lot of code to make sure it recovers  properly and keeps the
proper state.     For instance if the first statement executed fails for some reason, is the
queued method really going to be executed? Will server and client be in sync?   Maybe so in
this case but I know with XA there were really big problems with client code that tried to
keep track of the server's XA state.  

3) Queued up client requests are really hard to debug for everyone but the person who put
 that code in the first place because the execution is so far removed from the place where
it was expected.

Perhaps for setQueryTimeout these are not issues, but it is just a single round trip per setQueryTimeout
call,  so I don't think queing up requests really buys us a whole lot here in terms of performance.
 All that said I realize it is extra work to change the statement lookup, so I am not strongly
against your change as long as the three issues above have been considered.  In general though
I think  queuing up the protocol for multiple JDBC calls on the client side is bad news.

Regarding uprepared statements, I think the implications are the same with the queued approach
or sending the EXCSQLSET with the JDBC call. Unprepared update/delete/insert goes through
EXCSQLIMM rather than EXCSQLSTT, so would not be covered by  sending the EXCSQLSET with  EXCSQLSTT.
Selects even those not prepared in JDBC,  go the PRPSQLSTT-> EXCSQLSTT route.    Is setQueryTimout
relevant to statements other than selects?

> Implement Statement.setQueryTimeout in the Client Driver
> --------------------------------------------------------
>          Key: DERBY-506
>          URL: http://issues.apache.org/jira/browse/DERBY-506
>      Project: Derby
>         Type: New Feature
>   Components: JDBC
>     Versions:
>     Reporter: Oyvind Bakksjo
>     Assignee: Oyvind Bakksjo
>  Attachments: DERBY-506_PRE.diff
> Currently, the Embedded Driver supports Statement.setQueryTimeout(), but the Client Driver
does not. The Client Driver should be enhanced and match the Embedded Driver.
> For this, we need to transfer the timeout value from the client to the server, preferably
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; conceptually a "SET STATEMENT
TIMEOUT <seconds>" (this does not mean that we need to extend the Derby grammar; only
the Network Server needs to understand this DRDA EXCSQLSET command).
> * 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).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message