Mike Matrigali <[EMAIL PROTECTED]> writes: > 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 > case. > > 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 > java/engine/org/apache/derby/impl/sql/execute/HashScanResultSet.java > I didn't see holdability right off in this file, maybe someone can > add the right way to get this info in this class?
This is what my preliminary patch for DERBY-2462 does, I grabbed it from activation. > > 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. I think this has been tested with insensitive result sets, cf. also the test for DERBY-107, SpillHash.java, which does test holdability for insensitive result sets. If the test is adequate I can't say. > > 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? Should be investigated/verified. Dag > > 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 >> > -- Dag H. Wanvik Sun Microsystems, Database Technology Group (DBTG) Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43496/+47 73842196, Fax: +47 73842101
