db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Java 7 try-with-resources (AutoClosable) on Derby connections with auto-commit off
Date Fri, 17 Aug 2012 15:50:41 GMT
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.

>>> 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

Mime
View raw message