On 8/17/12 8:50 AM, Knut Anders Hatlen wrote:
Rick Hillegas<[email protected]> 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
