Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <10188148.1195574264338.JavaMail.jira@brutus>
Date: Tue, 20 Nov 2007 07:57:44 -0800 (PST)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3115) With embedded driver and autocommit,
 when closing a connection, updates on updatable result set are lost, unless
 result set is closed
In-Reply-To: <1371482.1191845450832.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543926 ] 

Daniel John Debrunner commented on DERBY-3115:
----------------------------------------------

> This leads me to the following implication chain:

>      closing connection => closing result set
>     => statement is completed
> and then autocommit.

Agreed, but that's not how the code is implemented. Ideally the implementation would follow the spec closely, so that the closing of the Connection triggers the closing of the ResultSet and that triggers the commit (if that means the statement is completed). Thus everything would follow naturally.  Calling a commit explictly at close time just means that it's an extra place that auto-commit logic is handled, though for Derby it might be the easiest, as long as it can be proved it is equivalent to what the standard defines.

> For callable statements it is more murky..
> For a callable statement, the is no guidance as to whether a closing
> of the connection also implicitly handles the outstanding inout and/or
> result count, but I think it is a reasonable, symmetric expectation. 

That would make life easier, seems like a reasonable assumption. Good to get this added to the JDBC 4.x spec in section 10.1, a statement is also completed when its connection is closed (explicitly??). This would also make the commit() in close() follow the spec. :-)

> I have pinged Lance again!

Thanks. Another interesting wrinkle of auto-commit mode according to the standard is that there is no application mechanism to rollback changes made through an updateable result set  when in auto-commit. This seems like a hole, something that would be fixed by allowing rollback() [and commit()] to be called even when in auto-commit mode (just as Derby does).

> With embedded driver and autocommit, when closing a connection, updates on updatable result set are lost, unless result set is closed
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3115
>                 URL: https://issues.apache.org/jira/browse/DERBY-3115
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.1.4
>            Reporter: Dag H. Wanvik
>         Attachments: Main.java
>
>
> With autocommit, if an application neglects to close the result set
> and/or the statement, the closing of the connection will lose any
> updates performed via an updatable result set.
> If autocommit is false, SQL state 25000 invalid transaction state will
> be thrown, however.
> The JDBC standard requires that statements be closed when the
> connection is closed, cf.  JDBC 4, section 9.4.4: "All Statement
> objects created from a given Connection object will be closed when the
> close method for the object is called."  For updatable result sets,
> closing the statement would lead to a closing of the result set, and
> hence a commit of the updates.
> For the network client it works as expected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.