On 25-2-2017 20:20, Vlad Khorsun wrote: > 25.02.2017 13:03, Mark Rotteveel wrote: >> As a client of a database, I want to make progress with my work, which >> means that processing rows is making progress, while waiting for an >> execute or a fetch of rows is not making progress. > > So, waiting for execute should be accounted in timeout but same waiting > for fetch - should not ?
See my reply to Dmitry. For my needs (to fulfill the JDBC requirements), I would need a timeout on execute and - optionally - a timeout on individual fetches. >> Yes, I might also >> have a deadline time for doing my own work, but that is not something I >> want my database driver to dictate or control. > > Don't set timeout in this case. > >> I will also quote what I said last year (2016-08-21): >> >> "I think a single timeout that is measured over the entire execute + all >> fetches is too brittle. I'd prefer if the timeout is applied to the >> execute and each individual fetch." > > "I think" and "I'd prefer" - not arguments, sorry. I showed my arguments > and they have not been disproved. And I showed my arguments in that same post back in 2016 when I quoted the JDBC requirements. > At that time (2016-08) the discussion was turned into a meaningless flame > by DS (as he likes to do), and I saw no reason to continue to "feed the > troll" (DS). Should note, nobody else continued that discussion, i.e. it was > out of interest. My replies where on the 21st of august and received no response, while DS latest post on that subject was on the 18th. > If client does something not related with db before commit - this is bad > practice and we can't make it good. That is a very narrow view of transactions. My business actions are the transaction, and they need to be successfully completed before I commit. >> The problem I foresee is that if I implement this in Jaybird, that I am >> going to get confused or irate Jaybird users, who either expect the >> timeout only to be applied to the execute, or only on 'time spent >> waiting for the server'. > > If you exclude time between fetches there will be another users who will > ask why statement still executed after specified timeout... Maybe, but the JDBC requirements I need to fulfill are clear, and pointing to an authoritative source like the JDBC apidoc and saying "we follow these requirements" is simple. Having to explain an alternative logic that is not applied by other JDBC drivers is not. >> 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. >> >> The requirements of JDBC would not entirely fit with having a 'total >> time spent in engine' timeout, but it is better than a 'lifetime of >> statement' timeout in my opinion. > > > https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#setQueryTimeout(int) > > ------------- > Sets the number of seconds the driver will wait for a Statement object to > execute to the given number of seconds. By default there > is no limit on the amount of time allowed for a running statement to > complete. If the limit is exceeded, an SQLTimeoutException is > thrown. A JDBC driver must apply this limit to the execute, executeQuery and > executeUpdate methods. > > Note: JDBC driver implementations may also apply this limit to ResultSet > methods (consult your driver vendor documentation for > details). > ------------- > > i see that query timeout scope is vendor specific. I see nothing more. > > I agree, fetches could be included into or excluded from timeout scope. > But i disagree that time between fetches could be treated separately. > And JDBC is silent about it. It says "may also apply this limit to ResultSet methods", so if the timeout is applied to ResultSet methods, the timeout is to be applied to individual method invocations. [..] > Mark. I don't want to argue again and again, it took to much time and > power from me and not makes me happier. As i already said, if feature is > considered bad\wrong\not correct, i rather abandon it. But i will not > do what i consider as a wrong. > > It is possible to convince me, btw. And i still have a hope you also > could be convinced ;) As I also mentioned in my reply to Dmitry, I guess I just won't use this (or at least: not for select statements), as it doesn't fit my needs. 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
