Thanks, Dag. I've added a JIRA bug, and attached the test program demonstrating the issue. We also are testing a patch that propagates holdability from the activation (very similar I bet ;-), but are also worried about side effects. I'd be interested in hearing about your experience.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 12:24 PM To: [email protected] Subject: Re: Possible problem in org.apache.derby.impl.store.access.BackingStoreHashTableFromScan Jeffrey Clary <[EMAIL PROTECTED]> 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 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'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 > > -- Dag H. Wanvik Sun Microsystems, Database Technology Group (DBTG) Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43496/+47 73842196, Fax: +47 73842101
