I am working on an application that is taking an exception iterating a result set after a different statement on the same connection commits. Holdability on the connection is set to HOLD_CURSORS_OVER_COMMIT and autocommit is true. The ResultSet.next() method does not take an exception the first time it is called after the other statement commits, but rather gets some number of (cached?) rows before taking this exception:
java.sql.SQLException: The heap container with container id Container(-1, 1173965368428) is closed. I have duplicated the problem in a small Java program attached to this email. This is the first time I have posted to this mailing list, so if the attachment doesn't work, I will repost and include the Java code inline. Note that the exception is related to the amount of data in the result set, so you may have to change the values in main() to get it to throw the exception. Is this a bug, or is it expected behavior? What I have been able to find on the holdability attribute suggests that the result set should be OK after the second statement commits. However, there are a few messages in the list archive that suggest I am not the first to encounter this. By the way, if holdability on the connection is set to CLOSE_CURSORS_AT_COMMIT then the very next call to ResultSet.next() throws an exception indicating the result set (not the backing store) is closed, as expected. On a more general note, is it a bad idea to be using more than one statement on the same connection, even if the holdability attribute is set to keep result sets around through commits? Thanks, Jeff Clary
DerbyHoldabilityTest.java
Description: DerbyHoldabilityTest.java
