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
DerbyHoldabilityTest.java
Description: DerbyHoldabilityTest.java
