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 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'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
>
>
--
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
