[
https://issues.apache.org/jira/browse/DERBY-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761442#action_12761442
]
Dag H. Wanvik commented on DERBY-4373:
--------------------------------------
Looking at the repro, the "new result set" that varies between drivers is a
COUNT(*) of the tmp table *after* one call to next() and then commit. Maybe for
the embedded case, a cursor is still open on tmp since one row has not been
read yet, so rows have not gone away, whereas for the client, all rows have
been prefetched, so the engine was free to remove the rows? If anything, I
think embedded shows wrong behavior here: the commit *has* happened, so it's ok
the delete the rows, I think.
> 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.0.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.
