[ 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 expectations. 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: 10.1.1.0 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
