Oliver Jowett wrote:
>>> Sorry. Of course the driver must handle failed connections. I meant
>>> the code in my application, which handles the two cases (timeout but
>>> usable connection vs broken connection for whatever reason) differently.
>>
>> You can check the SQLState of any exception thrown to tell the
>> difference, right?
Yes, i can check that. But if the connection is closed at this point,
that's no longer useful, except for diagnostics. This is, of course,
just the case where setQueryTimeout() is really "hard".
> Just to clarify:
>
> - If the soft query timeout goes off and the server cancels the query,
> you will get a server-generated SQLException saying the query was
> cancelled. This will be some non-fatal SQLState and generally looks like
> any other SQL error generated by the server. The connection and
> statement will still be live (and in fact IIRC the transaction is still
> live and you can rollback to a savepoint, etc, if you like)
>
> - If the hard query timeout goes off, you will get a SQLException
> generated by the driver that has whatever the SQLState for connection
> errors is (I can't remember offhand) - but it will look very similar to
> the exception you get for any other connection problem when running a
> query.
>
> Basically the "hard query" timeout just introduces a new cause of
> connection errors - "server didn't respond within the timeout". It will
> otherwise behave like any other network-level connection error.
The distinction between hard and soft timeouts makes sense in this way.
Please just make it so that hard timeouts are off by default.
Till