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