Rick Hillegas <[email protected]> writes: > On 8/16/12 2:44 AM, Knut Anders Hatlen wrote: >> Kristian Waagan<[email protected]> writes: >> >>> On 10.08.2012 18:29, [email protected] wrote: >>>> Rick Hillegas<[email protected]> 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
