David Fetter <david@fetter.org> wrote:
> Let's imagine you have a connection pooler with two clients,
> A and B.
I'm with you so far.
> A calls setQueryTimeout, then starts a query, which terminates in
> time, but dies before handling it.
Here you lost me. I don't know what that means.
> B connects to the pool, gets A's connection, and finds a
> statement_timeout that's not the default
Why? I would consider the JDBC QueryTimeout property to be
orthogonal to the server's statement_timeout GUC. Perhaps that's
why we're seeing things so differently.
> even though only A's single query was supposed to have that
> statement_timeout. This is not a situation that can be resolved
> without being able to set a timer *on the server side*.
That will be true if we conflate these two things. I don't think we
should.
http://download.oracle.com/javase/6/docs/api/java/sql/Statement.html#setQueryTimeout%28int%29
This time limit should apply to the overall time allowed in the
driver for the execute, executeQuery and executeUpdate of the Java
Statement object. It should not be trying to pick apart individual
SQL statements within the execute request, and it should not affect
any other statement on the connection.
I think both patches are making this harder than it needs to be.
-Kevin
