From derby-dev-return-97284-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Thu Aug 2 22:30:26 2012 Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B617790C1 for ; Thu, 2 Aug 2012 22:30:26 +0000 (UTC) Received: (qmail 27723 invoked by uid 500); 2 Aug 2012 22:30:26 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 27699 invoked by uid 500); 2 Aug 2012 22:30:26 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 27689 invoked by uid 99); 2 Aug 2012 22:30:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2012 22:30:26 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kristian.waagan@oracle.com designates 148.87.113.117 as permitted sender) Received: from [148.87.113.117] (HELO rcsinet15.oracle.com) (148.87.113.117) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2012 22:30:17 +0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q72MTtSO006294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Aug 2012 22:29:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q72MTs8J028869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 22:29:55 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q72MTsYG008841 for ; Thu, 2 Aug 2012 17:29:54 -0500 Received: from [10.175.50.30] (/10.175.50.30) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Aug 2012 15:29:54 -0700 Message-ID: <501AFF61.5060901@oracle.com> Date: Fri, 03 Aug 2012 00:29:53 +0200 From: Kristian Waagan Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Java 7 try-with-resources (AutoClosable) on Derby connections with auto-commit off Content-Type: multipart/alternative; boundary="------------050908070000080206010704" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------050908070000080206010704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Has anyone considered the case of using try-with-resources (Java SE 7) with Derby connections with auto-commit off? I haven't studied this in detail, but from what I can see the above configuration will cause Connection.close to throw an exception if a transaction is active. Based on what the Java API docs say, I think Derby is behaving in a way that's allowed [1]. Nonetheless, this may not be what users expect. I suppose one could work around this issue with an extra try-catch block, where you would call rollback/commit before rethrowing the exception, but this kind of defeats the purpose of try-with-resource. Connection.close implements AutoClosable.close so we can't have two different behaviors for the two [2] scenarios (try-with-resources vs explicit close). Have I missed something that makes this problem moot? Regards, -- Kristian [1] "It is *strongly recommended* that an application explicitly commits or rolls back an active transaction prior to calling the |close| method. If the |close| method is called and there is an active transaction, the results are implementation-defined." [2] Maybe one could use stack trace inspection, but that doesn't sound like a good solution. --------------050908070000080206010704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

Has anyone considered the case of using try-with-resources (Java SE 7) with Derby connections with auto-commit off?

I haven't studied this in detail, but from what I can see the above configuration will cause Connection.close to throw an exception if a transaction is active. Based on what the Java API docs say, I think Derby is behaving in a way that's allowed [1]. Nonetheless, this may not be what users expect.

I suppose one could work around this issue with an extra try-catch block, where you would call rollback/commit before rethrowing the exception, but this kind of defeats the purpose of try-with-resource.

Connection.close implements AutoClosable.close so we can't have two different behaviors for the two [2] scenarios (try-with-resources vs explicit close).

Have I missed something that makes this problem moot?


Regards,
--
Kristian

[1] "It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the close method. If the close method is called and there is an active transaction, the results are implementation-defined."
[2] Maybe one could use stack trace inspection, but that doesn't sound like a good solution.
--------------050908070000080206010704--