db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Java 7 try-with-resources (AutoClosable) on Derby connections with auto-commit off
Date Fri, 17 Aug 2012 12:38:18 GMT
On 8/17/12 2:17 AM, Knut Anders Hatlen wrote:
> 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.
Thanks for that clarification, Knut. The statement which I didn't 
understand was "I wouldn't expect that changing it would cause problems 
for existing
applications". I should have added my comment after that sentence rather 
than after the end of its paragraph.
>> 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.
By "specification" do you mean clarifications to the JDBC spec or the 
javadoc for AutoCloseable? Do you mean changes to Derby documentation? 
Something else?

If I understand this email thread correctly, there are a couple 
suggestions on the table:

1) Re-word the JDBC spec, the AutoCloseable javadoc, or Derby 
documentation. This suggestion may need some clarification.

2) Add a knob to Derby allowing applications to configure the behavior 
of Connection.close() when there is uncommitted in-flight work. The knob 
would let the application configure whether Connection.close() 
committed, rolled back, or raised an exception. The default would be the 
current behavior of raising an exception.

3) Change Connection.close() to always commit in-flight work or always 
roll back in-flight work.

Do people have other suggestions?

Thanks,
-Rick




Mime
View raw message