[
http://issues.apache.org/jira/browse/DERBY-506?page=comments#action_12331738 ]
Oyvind Bakksjo commented on DERBY-506:
--------------------------------------
I understand your points, but with regards to setQueryTimeout(), I honestly
think you're making too much of this. ;-) To make my point clearer, I don't
(logically) think of the setQueryTimeout call as a separate request which gets
queued, it's just setting an attribute of a statement before it is executed.
Without the execute, setting the attribute has no meaning, so it is ok to flow
the attribute together with the execute request. I don't see any issues with
keeping client and server in sync, and the only error message related to the
setQueryTimeout call we need to handle is if the user supplies a negative value.
Consider this:
PreparedStatement ps = connection.prepareStatement(SQL);
ps.setMaxFieldSize(512);
ps.setMaxRows(100);
ps.setFetchDirection(ResultSet.FETCH_FORWARD);
ps.setFetchSize(10);
ps.setQueryTimeout(10);
while (condition) {
....
ResultSet rs = ps.execute();
....
}
None of the other setX() calls result in a round trip to the server. The
difference, as I see it, is simply that the DRDA protocol does not have a field
for the timeout attribute (the protocol does not target JDBC, and SQL has no
such attribute for statements). This is what forces my slight "abuse" of
EXCSQLSET for transferring the attribute to the server.
I really think extra round trips are a big deal in terms of performance, so I
would prefer to avoid that. We have done some in-house performance comparisons
with other open source databases and discovered that Derby uses more round
trips per transaction than the others, and that this actually matters.
My point with unprepared statements is that you cannot send a timeout value in
an separate round trip and bind it to a statement which hasn't reached the
server yet, it has to flow with the execute operation. And yes, I know
unprepared statements use EXCSQLIMM, so I'll have to add the EXCSQLSET to this
operation as well (the patch I have attached was just meant to illustrate the
approach, it's not complete).
In my opinion, setQueryTImeout is relevant to all kinds of DML statements, not
just selects. (We already had a discussion about the semantics for timeout,
what it should apply to etc.)
> 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
