[jira] Updated: (DERBY-4373) different results with network server vs. embedded on select from a temporary table with resultset cursor hold over commit

["Rick Hillegas (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-4373:
---------------------------------

    Bug behavior facts: [Embedded/Client difference]  (was: [Embedded/Client difference, Wrong query result])

Turning off the "wrong query result" flag. It is ok to implicitly close the ResultSet when next() returns false, according to section 15.2.5 of the JDBC 4.0 spec (quoted below). Even though the client and embedded behaviors diverge, I agree with Knut's analysis that both behaviors conform to our governing standards.


--- Section 15.2.5 of the JDBC 4.0 spec ----

15.2.5 Closing a ResultSet Object 

A ResultSet object is explicitly closed when 
■ The close method on the ResultSet is executed, thereby releasing any external resources 
■ The Statement or Connection object that produced the ResultSet is explictly closed 

A ResultSet object is implicitly closed when 
■ The associated Statement object is re-executed 
■ The ResultSet is created with a Holdability of CLOSE_CURSORS_AT_COMMIT and an implicit or explicit commit occurs 

Note - Some JDBC driver implementations may also implicitly close the ResultSet when the ResultSet type is TYPE_FORWARD_ONLY and the next method of ResultSet returns false. 


> different results with network server vs. embedded on select from a temporary table with resultset cursor hold over commit
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4373
>                 URL: https://issues.apache.org/jira/browse/DERBY-4373
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.6.1.0
>            Reporter: Myrna van Lunteren
>         Attachments: repro_d4373.java
>
>
> Found this during review of conversion of declareGlobalTempTableJavaJDBC30 to junit (DERBY-2895) - when I tried to run the test with network server:
> We define a statement like so:
>         Statement s1 = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
>                     ResultSet.HOLD_CURSORS_OVER_COMMIT );
> and global temp table like so:
>             s1.executeUpdate("declare global temporary table SESSION.t1(c11 int, c12 int) on commit delete rows not logged");
> Then, we insert 2 rows, open a result set that selects *, then do commit.
> With a new resultset, we do another select, which with network server gives 0 rows, but with embedded, 2.

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