db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Clary" <jcl...@actuate.com>
Subject Possible problem in org.apache.derby.impl.store.access.BackingStoreHashTableFromScan
Date Fri, 16 Mar 2007 14:19:00 GMT
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


Mime
View raw message