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 17:44:39 GMT
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 

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
    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

View raw message