db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4373) different results with network server vs. embedded on select from a temporary table with resultset cursor hold over commit
Date Tue, 23 Nov 2010 15:16:13 GMT

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


Mime
View raw message