Dag H. Wanvik wrote:
Jeffrey Clary <[EMAIL PROTECTED]> writes:
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 think this must be a bug. Like you noted, the backing store for the
hash table used here is opened without setting the keepAfterCommit,
which is needed with holdability. I made a trial patch to propagate
this setting down from the activation, and the test works, but I don't
know about any possible side effects.
Does anybody know a reason for the comment on this line of code in
BackingStoreHashTableFromScan.java:101 ?
:
line 101 > false /* Do not keep the hash table after a commit. */);
:
I am sure this is left over from when we didn't support temp tables
held open across commits. It looks like holdability was not considered
when spill to disk was added. For a long time the code only supported
keeping these hash tables in memory, so holdability "came for free".
The initial scan would load all rows into memory and it would stay
around until user closed it.
I know we keep a hash backing store table across commits already in
the case of insensitive scrollable result sets; here is is used to
back up a hash join.
I forgot this had already been added, so your change seems likely to work.
I'll try to run the regression test with the patch and see if it blows up.
You may file a JIRA bug issue for this if you like, or, if you prefer,
I can do it.
Dag
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
