db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Possible problem in org.apache.derby.impl.store.access.BackingStoreHashTableFromScan
Date Fri, 16 Mar 2007 17:24:15 GMT
Jeffrey Clary <jclary@actuate.com> 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.


> 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

View raw message