this definitely looks like a bug, and I think you have the right
analysis. You should report a bug in JIRA with your findings and test
case.
If you are interested in working on it, some things to consider:
1) would need to get the holdability info all the way down from
execution into
the call. I think the interesting place is in
java/engine/org/apache/derby/impl/sql/execute/HashScanResultSet.java
I didn't see holdability right off in this file, maybe someone can
add the right way to get this info in this class?
2) need to check if temporary files are going to work right in
holdability case. It looks like when actual backing to disk was
added the holdability case was not considered.
Does anyone know if derby temporary files will work correctly if held
open past commit. Off hand I don't remember the process where they
are cleaned up - is that currently keyed by commit?
3) Are you interested in a workaround? If the hash got created in
memory rather than disk then this would probably work. I think
there are some flags to force bigger in memory hash result sets.
Jeffrey Clary wrote:
Folks,
I’m new to Derby and to these lists, so I’m not sure what I am reporting
is a bug or expected behavior. You can see an earlier question I asked
on the derby-user list 3/15/2007 titled “Heap container closed exception
(2 statements on same connection).”
I am not seeing the behavior I would expect after calling
Connection.setHoldability(ResultSet. HOLD_CURSORS_OVER_COMMIT). I have
attached a test program that displays the behavior. Here is an outline
of what happens (with autocommit on):
1. Execute a statement that returns a fairly large result set.
2. Execute another statement on the same connection that logically
does not affect the first result set, but that does update the database.
3. Iterate through the first result set.
4. After some number of calls to next(), take an exception
indicating “heap container closed.”
I have looked a bit into the Derby source code, and I think that the
issue is related to the
org.apache.derby.impl.store.access.BackingStoreHashTableFromScan
constructor. It passes a constant false value to its super in the
keepAfterCommit argument. In fact, there is a comment there that says
“Do not keep the hash table after a commit.” It seems to me that this
value should be based on the holdability attribute of the statement, as
set in the connection or when the statement is created. But knowing so
little about the Derby implementation I don’t have any idea whether that
would trigger some unintended consequence.
Any advice would be appreciated.
Thanks,
Jeff Clary
