|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [JDBC] Implementing setQueryTimeout() - round 2
Date: Mon Feb 18 2008 - 23:39:56 EST
Based on feedback so far here's attempt #2. The main thing I got out of
the feedback is that statement_timeout seems to be enough for most people.
Unfortunately statement_timeout is not sufficient for what I need, so my changes will end up doing more than that. Here's an attempt at a compromise:
Add 4 new connection parameters, associated connection / statement values and accessors on the postgresql extension interfaces:
- softQueryTimeout: 0=disabled, >0 = timeout in ms, default 0
- hardQueryTimeout: 0=disabled, >0 = timeout in ms, default 0
- softQueryMargin: -1=disabled, >=0 = margin in ms, default 0
- hardQueryMargin: -1=disabled, >=0 = margin in ms, default 60s
The soft query timeout (if enabled) makes the driver set statement_timeout before executing a query, which in most cases will result in a SQLException being reported if the timeout is reached (but this is not guaranteed).
The hard query timeout (if enabled) makes the driver forcibly close the connection after that timeout if the query has not completed, which will result in a fatal SQLException due to an IOException from the blocked query thread.
The setQueryTimeout(N) logic then looks something like this:
> if (N == 0) {
> softQueryTimeout = hardQueryTimeout = 0;
> return;
> }
>
> if (softQueryMargin == -1 && hardQueryMargin == -1)
> throw new PSQLException("not implemented");
>
> if (softQueryMargin != -1)
> softQueryTimeout = max(1,N*1000+softQueryMargin)
> else
> softQueryTimeout = 0;
>
> if (hardQueryMargin != -1)
> hardQueryTimeout = max(1,N*1000+hardQueryMargin)
> else
> hardQueryTimeout = 0;
The net effect is that if you call "setQueryTimeout(N)" by default you get an attempt at query cancellation after N seconds and a hard close of the connection after N+60 seconds.
Any comments on this iteration? Too configurable? Not configurable enough? Are the defaults sensible?
-O
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Received on Mon Feb 18 23:44:44 2008This archive was generated by hypermail 2.1.8 : Wed Jun 18 2008 - 23:44:51 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |