db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@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
Date Tue, 20 Nov 2007 14:13:43 GMT

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

Dag H. Wanvik commented on DERBY-3115:
--------------------------------------

Thanks for helping me figuring this out one, Dan!

> To really follow the JDBC spec I think what is needed is:
> 3) If Connection.close() leads to a statement being completed (JDBC
> 4 section 10.1) then a commit should be triggered.

I think the standard requires statements to be closed when connection
is closed(9.4.4), but "closed" may not (always) imply "completed"? If
they are not the same, then it would appear that, yes, a transaction
can still be active an an exception should be thrown.

Can you help me understand when that would be the case?

I can't understand how it is possible for selects:

Section 15.2.5 Closing a result set object says:

   A ResultSet object is explicitly closed when
     :
   - (bullet 2) The Statement or Connection object that produced the ResultSet is
      explictly closed.

This leads me to the following implication chain:

       closing connection => closing result set
       => statement is completed

and then autocommit. 

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.

So I still think 1a) is correct, at least for SELECTs. 

> JDBC 4 seems to indicate that both those ResultSets are open and can
> be used within a single auto-committed transaction. The transaction
> will be committed when rs1 or rs2 closes, whichever happens first.
> Note that Derby implements JDBC 3 in that it performs a commit (in
> auto-commit) on any execution within the connection. I wonder if
> JDBC 4 intended to make this change in behaviour.

Yes, I remember this one. I think it was intentional, but I have
pinged Lance again! If it is intentional, we could file another issue
for it.


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


Mime
View raw message