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] Updated: (DERBY-2462) org.apache.derby.impl.store.access.BackingStoreHashTableFromScan does not honor ResultSet holdability
Date Thu, 22 Mar 2007 02:22:32 GMT

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

Dag H. Wanvik updated DERBY-2462:

    Attachment: DERBY-2462-2.stat

This patch, DERBY-2462-2.{stat,diff} supercedes DERBY-2462-1.  It does
the following:

   - modifies the test lang/SpillHash.java to run the test cases both
     with and without holdability set for the three tests of the disk
     spill of the backing store hash table:

        * hash join result set 
        * distinct result set
        * scollable insensitive result set

     The changed test will reveal the same problem as the repro
     provided for this issue (if applied before the rest of this
     patch), as well as a failure of the distinct result set test case. 

   - modifies BackingStoreHashTableFromScan to use the holdable
     mode of the disk hash table if applicable to the query.
     This change was encessary to make the hash join test case
     of SpillHash.java work with holdability.
   - modifies DiskHashtable.java to enable its enumerator class
     ElementEnum to survives a commit. It uses a scan of the row
     conglomerate (heap). Under holdability, the scan gets closed at
     commit time, and ElementEnum#nextElement would fail. The patch
     reopens the scan if appropriate (under holdability).  In addition
     to the change in BackingStoreHashTableFromScan, this change was
     necessary to make the distinct test case of SpillHash.java work
     with holdability.

     I would especially appreciate if someone familiar with this area
     of the code could take a look at this part of the patch; the
     method I use for salvaging the scan is to save the row location
     after each nextElement, and use that to reopen the scan at the
     right position after a commit. I did not find a way to check
     if the scan was closed before attempting a fetch; I just catch
     the exception and check for SQLState.AM_SCAN_NOT_POSITIONED, in
     which I reopen the scan (only under holdability). I seems a bit of a
     hack; there may be a better way.

The patch fixes the repro, I ran derbyall and suites.All with no
errors on JDK1.6 under Solaris 10/x86. It is ready for review.

> 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, DERBY-2462-2.diff, DERBY-2462-2.stat,
> 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