On 25-2-2017 19:36, Dmitry Yemanov wrote: >> From the perspective of JDBC the statement query timeout is to be >> applied to the execute, and optionally for result set method calls. The >> wording in the specification is a bit vague, but the expectation is that >> the timeout is applied to each method individually. > > We looked at the setQueryTimeout() in JDBC while developing this > feature. The first description I googled right now: > > "The Java Database Connectivity (JDBC) API provides a standard interface > java.sql.Statement.setQueryTimeout to limit the number of seconds a JDBC > driver waits for a statement to execute. This is used by an application > to control the maximum amount of time the application waits for an SQL > statement to complete before the request is interrupted."
I'm not sure where you got this quote (Google seems to suggest it is from some IBM Websphere documentation), but both the JDBC API documentation (http://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#setQueryTimeout-int-) and the JDBC 4.2 specification (section 13.1.3) say on this subject: """ The setQueryTimeout method may be used to specify the minimum amount of time before a a JDBC driver attempts to cancel a running statement. A JDBC driver must apply this limit to the execute, executeBatch, executeQuery and executeUpdate methods. Once the data source has had an opportunity to process the request to terminate the running command, a SQLException will be thrown to the client and no additional processing can occur against the previously running command without re-executing the Statement. Note – Some JDBC driver implementations may also apply this limit to ResultSet methods. Please consult your driver vendor documentation for details. Note – In the case of Statement batching, it is implementation defined as to whether the time-out is applied to individual SQL commands added via the addBatch method or to the entire batch of SQL commands invoked by the executeBatch method. """ Note that I quoted this last year as well. > First of all, "time the application waiting for the statement to > complete" looks to me as surely including network delays and is not > limited to the server-side time consumption. It obviously means the time > elapsed from the application POV. > > Secondly, it says about statement execution. The problem is that it > doesn't necessarily mean execute(). I understand that JDBC users may not > expect the database "executing" the query while calling fetchNext(), but > this is how Firebird behaves. Any trivial select will be "completed" > only after the last row is fetched. From another side, the application > won't be "waiting" until that happens, it will be busy fetching rows. Non-authoritative sources are not authoritative. The above quote from the JDBC specification make clear that the query timeout is to be applied to the JDBC `execute...` methods, and optionally to result set methods as well. It also states "minimum amount", so if there is some network latency or other delays involved that is allowed. And the way I read it, the query timeout is to be used for each method execution individually, and if applied to result set methods that would mean a single ResultSet.next() call (which will only fetch if the fetch buffer is empty) would be allowed to take at most (queryTimeout) seconds. > What I can say is that the standard definition does not absolutely match > Firebird and thus should be taken with a grain of salt. If JDBC users > really expect execute() to do all the job, then you should be fetching > and caching the entire result set inside Jaybird's execute() thus > keeping them in happy ignorance. But I doubt you do that. We need to > find some compromise. JDBC users don't expect execute() to do all the work (although Jaybird currently does do that with simulated scrollable result sets), but the timeout is to be applied to individual method executions, not over the entire lifetime of the query. That is why I'd prefer if timeout is applied to execute and fetches individually. But given this discussion, it looks like I just won't use this feature (or at least: not for select statements) and instead I will have to implement client-side timeouts. The upside of that is that it would be available to Firebird 2.5 and instead of only Firebird 4 an up. Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
