db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Possible problem in org.apache.derby.impl.store.access.BackingStoreHashTableFromScan
Date Fri, 16 Mar 2007 18:52:22 GMT


Dag H. Wanvik wrote:
> 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 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
>>
>>
> 
> 


Mime
View raw message