[
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 cursor),
> 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 above.
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 holdability
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-2462
> URL: https://issues.apache.org/jira/browse/DERBY-2462
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0
> 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.
