db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Java 7 try-with-resources (AutoClosable) on Derby connections with auto-commit off
Date Fri, 17 Aug 2012 09:17:49 GMT
Rick Hillegas <rick.hillegas@oracle.com> writes:

> On 8/16/12 2:44 AM, Knut Anders Hatlen wrote:
>> Kristian Waagan<kristian.waagan@oracle.com>  writes:
>>> On 10.08.2012 18:29, dag.wanvik@oracle.com wrote:
>>>> Rick Hillegas<rick.hillegas@oracle.com>   writes:
>>>>> Thanks for the code snippet, Kristian. I don't see this as a Derby
>>>>> problem.
>>>> Hmm.. IMHO I'd like a close that does what I tell it. In my mind that
>>>> means rolling back and closing.
>>> That's exactly what I felt after having written a simple app using
>>> autoclosable.
>>> Just wanted to hear if anyone else had stumbled across this behavior
>>> and given it any thought.
>>>> That the current behavior doesn't play well with autoclosable is a (new)
>>>> argument for changed behavior.
>>> Yes, I hope this is brought up again when we're at a point where we
>>> can change the current behavior without too much trouble.
>> If we think changing it is the right thing to do, I'd say that now is
>> the right time to do it on trunk. Then we'd have plenty of time to fix
>> any fallouts before the next feature release.
>> I wouldn't expect that changing it would cause problems for existing
>> applications, as it will only make calls that used to fail, succeed. In
>> fact, many users have found the current behaviour surprising.
> I don't understand this.

I guess they're surprised because they've used other JDBC drivers, such
as MySQL and PostgreSQL, which silently abort the transaction when the
connection is closed.

> For some applications the correct behavior
> is "oops, an error occurred, I don't know what state I'm in, I'd
> better throw away the uncommitted work and get out." For other
> applications the correct behavior is "oops, an error occurred, oh
> well, everything up to that point was good so save that work and get
> out." I think the second behavior is appropriate for applications
> which could correctly operate in autocommit mode but which batch a lot
> of statements into bigger commits for performance reasons.

Yes, there's no way to know which of the two options is what the
application wants, and that's why we're currently raising an exception.
Since the JDBC specification (since 4.0) explicitly states that the
results are implementation-defined, the application won't be portable
unless it calls rollback() or commit() before it closes the connection.
Making it more convenient to use Connection together with
try-with-resources in a portable manner, is probably more of a
specification task than an implementation task.

Knut Anders

View raw message