Oliver Jowett wrote:
> Till Toenges wrote:
>> Oliver Jowett wrote:
>>>> A network timeout or anything worse is handled in an entirely
>>>> different part of the code. That is not the responsibility of the
>>>> driver, and doesn't event need to be part of the database related
>>>> code at all.
>>>
>>> I'm not sure what you mean here - if the connection to the DB fails,
>>> the driver will certainly handle that and tell you about it via a
>>> SQLException!
>>
>> 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?
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.
-O