All, Let me jump into discussion and share my own concerns.
Depending on the plan, statement may take 99% of its "working" time inside execute() or inside fetch() or that time could be distributed among the API calls. Neither client nor DBA has any control on that. So I consider seriously wrong removing fetching time from the accounting. From the client side, a timeout can be seen from two different angles. It could be either statement execution time (including fetches, see above) - this is what we have implemented now. Or it could be the API call timeout, to avoid "blocking" for more than the specified time. This means that any higher-level accounting should be done by the application or connectivity library. I guess the latter approach gonna cost much more due to often timer resets. It also adds more work to the client-side developers. Now about what is "working time". If the client specifies 10 seconds, I really doubt it expects to see the statement timing out after 30 seconds. From the client POV, "working time" includes all the waits, round-trips and so on. It's not about server resources, they are outside client's business. It's rather about an application reaction time. So I consider Vlad's position perfectly valid. And I'm surprised that Mark and Jiri disagree. For server-side statement timeouts, situation is a bit different. It's really about long-running queries and server resources. DBA can hardly guess about application logic (time between fetches) or about network latencies. So if we speak only about engine doing some work, performing disk I/O or waiting for something, then Sean's point has some value. Of course, it has nothing to do with CPU time spent, it's more about time spent inside the engine for whatever reason. But it surely defines "long-running" statements from one side, as something being served by the engine. From another side, we have long-running "sleeping" (even if occasionally) statements that block metadata objects, occupy memory and freeze transaction counters. These are different resources but it does not mean they should be ignored. Vlad's solution accounts that, Sean's does not. So we have different requirements for the same feature and they conflict with each other. The positive side of the implemented solution is that it suits both client-side and server-side usage. Sean's suggestion does not fit client-side usage, IMO. Also, if the timer is suspended/resumed too often (per every fetch call), it gonna be costly. That said, I'd vote against reworking the current design. Perhaps, we could additionally implement what Sean suggests, but *only* at the server side. But I have no idea how to mix them nicely. Having two independent timeouts looks ugly, complicates the engine code and is likely to confuse users. Dmitry ------------------------------------------------------------------------------ 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
