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 16:49:24 GMT
On 8/17/12 8:50 AM, Knut Anders Hatlen wrote:
> Rick Hillegas<rick.hillegas@oracle.com>  writes:
>> 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".
> What I meant was that existing applications written against Derby will
> already have been coded so that they explicitly commit or abort the
> transaction before they close the connection. This means they are not
> likely to be affected by a change in how we handle closing of active
> transactions.
I think many applications may have addressed the problem that way. 
However, I think other applications may put the compensatory logic in a 
catch block. That may seem goofy to us, but it may make sense to someone.
> ...
>> 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?
> I think the current behaviour is fine, as we essentially raise an error
> to tell the application it is attempting to do something that's not well
> specified and not portable.
> However, if someone feels strongly for option (3), I wouldn't object
> very much, as the method would still follow the JDBC spec, the change
> would be backward compatible, and the behaviour would match at least the
> two other JDBC drivers I checked (MySQL and PostgreSQL).
I remain concerned about backward compatibility and would object to 
option (3).


View raw message