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