db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4373) different results with network server vs. embedded on select from a temporary table with resultset cursor hold over commit
Date Mon, 04 Oct 2010 10:48:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917553#action_12917553

Knut Anders Hatlen commented on DERBY-4373:

Thanks for analyzing this issue, Mamta.

>From you description, it sounds to me like what the network client does is not necessarily
wrong, just different. Since the forward-only result set has been exhausted, the caller cannot
actually use the result set anymore, and that's why the server thinks it's ok to close the
cursor earlier.

The lifetime of a cursor may differ between client and embedded in both ends. The client will
start fetching rows from the cursor on executeQuery(), whereas embedded won't do it until
next() is called. And the client driver will release the resources held by a forward-only
result set when the last row has been fetched, whereas the embedded driver waits until ResultSet.close()
is called. These differences cause some differences in when locks are obtained and released,
but they also make it possible to save two round-trips between the client and the server for
many SELECT statements.

I'm willing to accept that client and embedded behave differently on the boundaries in this
case. So I'd be satisfied with a solution that makes the test expect a difference between
client and embedded (with an explanation in a comment), or one that makes the test use a result
set that's not exhausted when testing that an open held cursor prevents emptying the temporary
table. But if you still want to make the drivers behave the same way on the boundaries, please
make sure that you don't add extra client/server round-trips on close for queries that don't
access temporary tables.

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

View raw message