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. >>> 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. >> >> Yes, there's no way to know which of the two options is what the >> application wants, and that's why we're currently raising an exception. >> Since the JDBC specification (since 4.0) explicitly states that the >> results are implementation-defined, the application won't be portable >> unless it calls rollback() or commit() before it closes the connection. >> Making it more convenient to use Connection together with >> try-with-resources in a portable manner, is probably more of a >> specification task than an implementation task. > > By "specification" do you mean clarifications to the JDBC spec or the > javadoc for AutoCloseable? Do you mean changes to Derby documentation? > Something else? I meant the specification of the try-with-resources language feature and/or the specification of java.sql.Connection's close method. For example, if the JDBC spec said that calling Connection.close() on an active transaction would cause the transaction to be rolled back and the connection to be closed, Connection could be used with try-with-resources without nested try/finally clauses to handle cleanup. But I guess there's probably a good reason why the JDBC spec says the result is implementation-defined, so I'm not sure it's very likely that it'll ever be more well-specified. What I tried to say, was that making language features and APIs play well together is primarily a job for those who design the language and the APIs, and that there's not so much we, who merely implement the APIs, can do. > 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). Option (1) isn't under our control, so there's not much we can do. (Except for the documentation part, but it looks like we already document the current behaviour in the topic "Explicitly closing Statements, ResultSets, and Connections" in the developer's guide.) I'm not in favour (2), as I don't think the benefit justifies another knob. One well-defined behaviour of close() is better than three. :) -- Knut Anders
