db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2462) org.apache.derby.impl.store.access.BackingStoreHashTableFromScan does not honor ResultSet holdability
Date Tue, 20 Mar 2007 03:53:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482304

Dag H. Wanvik commented on DERBY-2462:

Dag said:

> I see the test for insensitive result sets (which also relies on
> spilling the hash table to disk) uses holdability=true, but the test
> for join and DISTINCT only tests the non-holdable case. 

Checking the test SpillHash.java (from DERBY-106) further, I see that
none of the cases actually do run with holdability: Apparently the
case for insensitive result sets does, but I got misled by the fact
that the test relies on the metadata method
supportsOpenCursorsAcrossCommit() which always returns false for
Derby, as it turns out, since we do not support holdability for XA. So
the test chooses to run without holdability.

When enabling holdability in the test cases in SpillHash.java, I see
the following:
 - hash join fails with the same error as reported in this issue, 
 - scroll insensitive result sets work (to be expected, has other
 - DISTINCT fails with an exception NoSuchElementException in 

My first patch fixes the hash join case, but not the DISTINCT case,
because this accesses the spilled rows in the hash tabledifferently;
it uses a heap scan which fails (the hash join case accesses the
spiiled rows via a btree lookup of the hash key) since the scan is
closed due to the commit, and not reopened. I am working on a patch
which fixes this as well.

> org.apache.derby.impl.store.access.BackingStoreHashTableFromScan does not honor ResultSet
> -----------------------------------------------------------------------------------------------------
>                 Key: DERBY-2462
>                 URL: https://issues.apache.org/jira/browse/DERBY-2462
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,
>         Environment: Test under Windows Vista, Java 1.4.2_13
>            Reporter: Jeff Clary
>         Assigned To: Dag H. Wanvik
>         Attachments: DERBY-2462-1.diff, DERBY-2462-1.stat, DerbyHoldabilityTest.java
> After an unrelated statement on the same connection commits, and after some number of
successful calls to ResultSet.next(), a subsequent call to ResultSet.next() throws an SQLException
with a message like: The heap container with container id Container(-1, 1173965368428) is
closed.  This seems to be related to the hard-coded passing of false to the super in the constructor
of org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.
> Steps to reproduce:
> 1. Execute a statement on a connection that returns a result set.
> 2. Execute a second statement on the same connection that modifies the database and commits.
> 3. Call next() on the first result set until the exception is thrown.
> Note that the number of rows that can be successfully retrieved from the result set seems
to be related to the amount of data per row.  Increasing the number of columns in the result
set or the length of the columns causes the exception to be taken sooner.
> The attached test program demonstrates the issue.

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

View raw message