Re: BUG org.postgresql.Driver.connect() distorts InterruptedException

From: Andreas Rudolph <andreas(dot)rudolph(at)spontech-spine(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: BUG org.postgresql.Driver.connect() distorts InterruptedException
Date: 2013-08-13 15:19:53
Message-ID: 1543F7DE-67DE-4210-A594-E87726E4DA6C@spontech-spine.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc


Am 12.08.2013 um 18:22 schrieb Dave Cramer <pg(at)fastcrypt(dot)com>:

> Ok, so you would like the code to not reset the interrupted exception so that when it returns the interrupted bit will still be set and you can check for isInterrupted ?
It would be acceptable to set the interrupted flag again and throw a PSQLException without the cause set (to the InterruptedException) to signal that no connection has been established to the caller. Then client code could catch the exception and notice that the connect request failed. Additionally it could examine the interrupted flag. That way it could at least detected that it (the calling thread) has been interrupted. However, theoretically a PSQLException could have been thrown for some other reason and at the same time interruption may occur. Because of that client code cannot reliably tell whether the connection failed because of interruption. Client might want to know this is because it would behave differently, for example it could decide to log connect failures except for interruption.

>
> The SQL error is rather vague here since it is not really a SQL error, rather someone cancelled the thread.
I agree. Most of the time SQL errors refer to something that happened on the server. I just mentioned it for completeness.

>
>
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Fri, Aug 9, 2013 at 4:35 AM, Andreas Rudolph <andreas(dot)rudolph(at)spontech-spine(dot)com> wrote:
> Hi there!
>
> + JDBC driver build number
> 9.1-903
>
> + Server
> PostgreSQL 9.1.9 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 32-bit
>
> + Error message / stack trace
>
> org.postgresql.util.PSQLException: Beim Verbindungsversuch trat eine Unterbrechung auf.
> at org.postgresql.Driver$ConnectThread.getResult(Driver.java:365)
> at org.postgresql.Driver.connect(Driver.java:269)
> …
>
> + Description
>
> Recently I discovered this problem because it prevents to tell other SQLExceptions and interruption apart (in the exception handlers). After examining the source of org.postgresql.Driver I noticed that org.postgresql.Driver$ConnectThread.getResult catches InterruptedException and throws a org.postgresql.util.PSQLException instead BUT without supplying the InterruptedException as the cause (exception chaining) and without resetting the interrupted flag via Thread.currentThread().interrupt() (SQL error code / SQL state is unspecific, too). Please note that this behavior is present in 9.2-1003, too.
>
> Therefore I suggest that the handling of InterruptedException should be changed so it becomes more interoperable with client code that needs to handle SQLExceptions differently from thread interruption -- in a concurrent environment an already scheduled database query may become obsolete before it finishes because another query may be needed for example because of user intervention.
>
> Greetings
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Andreas Rudolph 2013-08-13 15:41:59 Re: BUG org.postgresql.Driver.connect() distorts InterruptedException
Previous Message Mikko Tiihonen 2013-08-13 11:07:18 Re: BUG org.postgresql.Driver.connect() distorts InterruptedException