Lance Andersen lance.andersen at
Wed Feb 17 19:25:52 UTC 2021

Hi Filipe,

As Douglas points out at the time of the discussion,  the JDBC EG consensus was the Statement would be closed.  If applications did not want this behavior they should not call Statement::closeOnCompletion and if they were not sure if the method had been invoked, they could always call Statement::isCloseOnCompletion to make a decision programatically.

This area as you are aware is messy enough and the intent was to address a common use case which lead to common issues for applications and not further complicate things.



On Feb 17, 2021, at 2:14 PM, Filipe Silva <filipe.silva at<mailto:filipe.silva at>> wrote:

Hi Douglas,

Wait, this is not the question here, there is no doubt that closing the result sets closes the statement. The question is whether a statement with `closeOnCompletion` and an active results set (not closed yet) can be re-executed or not. In different words, implicit closing of open result sets on next statement execution triggers `closeOnCompletion` and closes the statement or should it execute?


On 17/02/21 19:03, Douglas Surber wrote:
As I said I wrote the original proposal and what I intended and what the EG discussed at the time at least implicitly was that closing the open ResultSet would close the Statement and that no subsequent execution was possible. No this wasn't spelled out in the discussion. It was clearly the intent as the purpose of the method was to handle the case Lance described.

Maybe the language is unclear but I don't think that would justify expanding the behavior of the method to cover your use case. The goal is to support a specific use case. Any change to the spec should be to more clearly state how that use case is supported, not to expand the meaning to support additional use cases, especially a use case that has never come up in practice.

From: Filipe Silva <filipe.silva at><mailto:filipe.silva at>
Sent: Wednesday, February 17, 2021 10:55 AM
To: Dave Cramer <davecramer at><mailto:davecramer at>; Douglas Surber <douglas.surber at><mailto:douglas.surber at>
Cc: Lance Andersen <lance.andersen at><mailto:lance.andersen at>; jdbc-spec-discuss at<mailto:jdbc-spec-discuss at> <jdbc-spec-discuss at><mailto:jdbc-spec-discuss at>
Subject: Re: closeOnCompletion

Well, looks strange to me. I explain why in the an answer I wrote in StackOverflow (
Moreover, IMO, allowing re-executions doesn't conflict with the use case below and it allows more.
On 17/02/21 18:38, Dave Cramer wrote:

On Wed, 17 Feb 2021 at 13:33, Douglas Surber <douglas.surber at<mailto:douglas.surber at>> wrote:
I wrote the original proposal. The intent was to handle the case Lance described. It was not intended to allow multiple executions of the Statement. So while the language may not be as clear as it needs to be, the case Filipe described should throw on the second execution of the Statement. At least that was my intent.

Well there's enough hints in the wording to figure that out, but they are just hints.
We (postgres) are going to implement it in such a way that the statement will not be executed twice


From: jdbc-spec-discuss <jdbc-spec-discuss-retn at<mailto:jdbc-spec-discuss-retn at>> on behalf of Lance Andersen <lance.andersen at<mailto:lance.andersen at>>
Sent: Wednesday, February 17, 2021 9:52 AM
To: Dave Cramer <davecramer at<mailto:davecramer at>>
Cc: Filipe Silva <filipe.silva at<mailto:filipe.silva at>>; jdbc-spec-discuss at<mailto:jdbc-spec-discuss at> <jdbc-spec-discuss at<mailto:jdbc-spec-discuss at>>
Subject: Re: closeOnCompletion

I will have to go dig back through my email archive as this was first discussed in 2009.

The overall intent was to deal with code similar to:

ResultSet rs = foo();
 while( {
     /*do something */

public ResultSet foo() {

   Statement stmt = con.createStatement();
   ResultSet rs = stmt.executeQuery(aQuery);
   return rs


We did spend a lot of time on this back in 2009 and took quite a bit of time to reach agreement on the current wording.  However, it does  look like there is the potential for some additional word smithing.


On Feb 17, 2021, at 12:34 PM, Dave Cramer <davecramer at<mailto:davecramer at><mailto:davecramer at<mailto:davecramer at>>> wrote:

On Wed, 17 Feb 2021 at 12:13, Filipe Silva <filipe.silva at<mailto:filipe.silva at><mailto:filipe.silva at<mailto:filipe.silva at>>> wrote:

On 17/02/21 10:53, Dave Cramer wrote:
Interesting situation.

If we have an open statement with open resultsets and call
closeOnCompletion and then execute the statement a second time the
statement will throw an already closed exception since the spec says that
executing a statement a second time closes any open resultsets. Closing
said resultsets ends up closing the statement.

I'm just confirming that this is the intended behaviour. Seems about
since if you set closeOnCompletion you would not expect to re-use the

Dave Cramer
No, I don't think it is supposed to work like this. "Completion" means
that the user is done with the ResultSet(s) and explicitely calls
close() on it/them.

Successive executions do close previously opened ResultSets but closing
those ResultSets implicitely (by re-executing) do not close the
Statement. The documentation makes it clear when it says "a call to
|closeOnCompletion| does effect both the *subsequent execution of
statements*, (...)". There would be no "subsequent execution of
statements" if the behavior was the one you described.

Well interestingly I'm told that the Oracle driver does close the statement
on subsequent execution.

Either way I'm not sure I agree with the inference. Now we have to debate
the word execution. Is calling the method an execution or is completing the
call an execution ?

Dave Cramer

Filipe Silva, Senior Software Developer
Mobile: +351.91.009.2110
MySQL Middleware and Clients
Oracle Portugal, Lagoas Park, Edifício N.º 8, 2740-244 Porto Salvo

Filipe Silva, Senior Software Developer
Mobile: +351.91.009.2110
MySQL Middleware and Clients
Oracle Portugal, Lagoas Park, Edifício N.º 8, 2740-244 Porto Salvo

More information about the jdbc-spec-discuss mailing list