Oliver Jowett <oliver(at)opencloud(dot)com> wrote:
> Kevin Grittner wrote:
>
>> I could take a shot at a patch if nobody disagrees with making this
>> change.
>
> What exactly is the change you're suggesting?
I need to go back and see if any earlier versions conflict with this,
but recent version of the Java API specify that commit and rollback
should throw a SQLException if autoCommit is true. The driver
currently returns without any warning or exception, and without doing
anything.
There is a similar requirement for these methods when a distributed
transaction is active, which is only mentioned in Java 6 javadocs, but
seems as though it makes sense whenever distributed transactions are
used. Java 6 also explicitly mentions that an exception should be
thrown for attempts to use these methods on a closed connection,
although that could arguably fall under the earlier language requiring
an exception when "a database access error occurs" -- since you can't
access a database across a closed connection.
This surfaced because a popular connection pooler is reportedly
failing to behave correctly when the connection is lost (for example,
if PostgreSQL is restarted). It works with other databases the user
has tested. The user believes it to be because the rollback method is
not throwing an exception on the closed connection. I haven't
independently confirmed this yet. (Takiguchi, if you have a
self-contained test case, that would save me some time on that point.)
I'm suggesting that we throw exceptions for all of the above. It
worries me that some existing applications may be relying on the
silent success of a commit or rollback when autoCommit is active,
though. That's contrary to the javadocs for the API, but there's
still the backwards compatibility issue for current PostgreSQL
users....
-Kevin