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 Thu, 16 Aug 2012 12:46:18 GMT
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.  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.


View raw message