db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oyvind Bakksjo (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-506) Implement Statement.setQueryTimeout in the Client Driver
Date Mon, 10 Oct 2005 18:56:48 GMT
    [ 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);
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:
>     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