Re: executeQuery() throws "Statement has been closed"

Candidly I think it's time to review this statement:

According to http://jdbc.postgresql.org/documentation/81/thread.html , JDBC
connections are threadsafe and can be used by multiple threads concurrently.

That page also reads,
"If a thread attempts to use the connection while another one is using it,
it will wait until the other thread has finished its current operation. If
the operation is a regular SQL statement, then the operation consists of
sending the statement and retrieving any ResultSet (in full)."

There are some things which will not be concurrent safe. For instance if
you change the transaction isolation in one thread, it will change it for
all the threads.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 31 July 2014 15:33, Hannes Erven <hannes(at)erven(dot)at> wrote:

> Dave,
>
>
>
> > Sharing one connection across multiple hibernate sessions seems
> > fraught with danger ?
>
> sorry, I should have explained better. This is a read-only ("SELECT")
> workload, so there are no commits etc. interfering between threads. This is
> a session-per-view pattern so the indiviual sessions have minimal size and
> may be closed and garbage collected independently.
> Access to the backend is again pooled through a pgbouncer statement pool
> (which might be another place to look at).
>
>
> According to http://jdbc.postgresql.org/documentation/81/thread.html ,
> JDBC connections are threadsafe and can be used by multiple threads
> concurrently.
>
> That page also reads,
> "If a thread attempts to use the connection while another one is using it,
> it will wait until the other thread has finished its current operation. If
> the operation is a regular SQL statement, then the operation consists of
> sending the statement and retrieving any ResultSet (in full)."
>
>
> As I understand it, even if one thread closes the connection, a call to
> executeQuery() should either fail early or complete. It appears to me that
> is is not the case in these rare instances where the exception is thrown
> only when the results have already been processed successfully.
>
>
> As Kevin pointed out (thanks!), getMaxRows() is required by the spec to
> check whether the connection is still open.
> So let me rephrase the question: why is AbstractJdbc4Statement.createResultSet()
> calling getMaxResult() and friends [which in turn check for openness]
> instead of directly using the already prepared field values?
>
>
> In any case, I'll see if I can come up with a test case to demonstrate.
>
>
> Thanks again,
> best regards
>
> -hannes
>