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