23.02.2017 19:02, Leyne, Sean wrote:
...
> Unfortunately, I doubt that the feature as implemented has any benefits for 
> our applications.
>
> We have a number of our clients that access our databases via ODBC/JDBC 
> connections to perform data extract.
>
> These connections perform only a few heavy weight SQL statements (taking max 
> 3-4 of real execution time).
 > Most of the time is spent in the Firebird engine waiting for the next fetch, 
 > due to network latencies.

   In the engine ? Probably you want to say in the application\client ? Also it 
is very interesting how
do you evaluate that numbers.

 > Some of these extract functions/statements run for 60+ minutes.
>
> Without the ability to not have time "waiting for fetch" not included in the 
> timeout, we would need to set
 > default timeout value so high (ie. 90 minutes) that the real benefit of 
 > preventing/stopping "run away/stupid"
 > queries would be completely lost -- even with the ability to set timeout on 
 > a connection or transaction basis.

   The main question is - do you need such benefit at all, and, if so, how much 
efforts you are willing to
spend on it ?

If you still needs in it, i can suggest the following:
- don't set statement timeout on database level at all (leave it zero)
- control statement timeout in application:
   - at connection level set timeout to the value which will guard you from 
"stupid mistakes", say 10 min or so
     (it is easy to do right after connection is established)
   - set timeout to high value (90 min) at the stmt level when it is expected 
to run too long,
     (it requires support from access layer)

   If you insist on changes in implementation, please, specify exactly what you 
need and where it is implemented
in a such way.

Regards,
Vlad

PS Last try to convince you: imagine application which set timeout to 10 sec, 
run some query and fetching results.
With current implementation it is expected that query will be cancelled in a 10 
sec after execution starts.
With you offer it is impossible to guess when it will be cancelled.


------------------------------------------------------------------------------
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

Reply via email to