Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of rick.hillegas@oracle.com
 designates 141.146.126.227 as permitted sender)
Message-ID: <502E7614.8060608@oracle.com>
Date: Fri, 17 Aug 2012 09:49:24 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Java 7 try-with-resources (AutoClosable) on Derby connections
 with auto-commit off
References: <501AFF61.5060901@oracle.com>
 <501BC91D.8050601@oracle.com>	<5022786D.1000401@oracle.com>
 <502281EA.60908@oracle.com>	<x6d32yk8wg.fsf@oracle.com>
 <502BACB2.1040101@oracle.com>	<wjo8mx1vdvcn.fsf@khepri41.no.oracle.com>
	<502CEB9A.8080201@oracle.com>	<wjo84no1j2rm.fsf@khepri41.no.oracle.com>
	<502E3B3A.2090608@oracle.com> <wjo8obm9h60e.fsf@khepri41.no.oracle.com>
In-Reply-To: <wjo8obm9h60e.fsf@khepri41.no.oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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