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. 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.
Thanks,
-Rick
