db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2462) org.apache.derby.impl.store.access.BackingStoreHashTableFromScan does not honor ResultSet holdability
Date Wed, 25 Apr 2007 16:14:15 GMT

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

A B commented on DERBY-2462:

Thank you _very_ much for the detailed analysis, Dag.   I feel better about the "safety" of
your v3 changes after reading your previous comment.

>  Maybe a (even more) generally useful method could be:
>    public boolean isHeldAfterCommit() throws StandardException
>    {
>        return (scan_state == SCAN_HOLD_INIT ||
>                scan_state == SCAN_HOLD_INPROGRESS);
>    } 
>  that is, if this returns true, the scan can always be reopened
>  (although in the case at hand, only the second state tested for may
>  occur as shown above).
>  What do you think?

+1, I like this idea even better.  Thank you for the suggestion and for your willingness to
implement it.

> I manually modified the test to verify that for all three variants (join, distinct and
> this happened. If you this it is still advisable, I can add those tests cases to SpillHash.

If it's not too much work I think this would be good.  I'm sure there are tests elsewhere
to check the general concept of cursor holdability across commits, but it might be nice to
have a test case for the specific scenario of a spilled DiskHashtable.

> If you agree, I will make a version of the patch with the new isHeldAfterCommit outlined

Sounds great.  Thanks again for your continued work with this, and for your prompt consideration
of my feedback.

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