[ http://issues.apache.org/jira/browse/DERBY-1058?page=comments#action_12368265 ]
Andreas Korneliussen commented on DERBY-1058: --------------------------------------------- This is broken for current holdable result sets, on the 10.1 release,. I think the BackingStoreHashTable does everything correctly. It opens the BTree controller with a call which has "hold" set to true. The problem is that this parameter is ignored when creating the BTreeController from B2I.open, and the assert. To fix this, I did the following: - ensure that the holdable parameter get propagated to the BTreeController - removed the assert I would like to add tests for this issue in DERBY-1070 > derby fails supporting holdable scrollable resultset: ERROR XSCB8: The btree > conglomerate 1,141,037,436,752 is closed. > ---------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1058 > URL: http://issues.apache.org/jira/browse/DERBY-1058 > Project: Derby > Type: Bug > Components: SQL, Store > Versions: 10.1.2.1 > Environment: All > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > Attachments: HoldabilityIssue.java > > If the ResultSet is so big that the scrollable resultset needs to back the > hashtable to disk, and the resultset is not fully populated before a commit(), > a call to next() will fail with: > [EMAIL PROTECTED]:/<3>db-derby-10.1.2.1-bin/lib> java -cp > /home/ak136785/devel/derbytesting/derbytest/build/classes/:./derby.jar > derbytest.HoldabilityIssue > ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed. > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.BTreeController.insert(Unknown > Source) > at > org.apache.derby.impl.store.access.btree.index.B2IController.insert(Unknown > Source) > at org.apache.derby.iapi.store.access.DiskHashtable.put(Unknown > Source) > at > org.apache.derby.iapi.store.access.BackingStoreHashtable.spillToDisk(Unknown > Source) > at > org.apache.derby.iapi.store.access.BackingStoreHashtable.add_row_to_hash_table(Unknown > Source) > at > org.apache.derby.iapi.store.access.BackingStoreHashtable.put(Unknown Source) > at > org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.addRowToHashTable(Unknown > Source) > at > org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(Unknown > Source) > at > org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(Unknown > Source) > at > org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source) > at derbytest.HoldabilityIssue.runTest1(HoldabilityIssue.java:72) > at derbytest.HoldabilityIssue.main(HoldabilityIssue.java:91) > [EMAIL PROTECTED]:/<3>db-derby-10.1.2.1-bin/lib> > The BtreeController is always initialized as non-holdable, and if this is > changed, Derby has the following assert in closeForEndTransaction(..): > SanityManager.THROWASSERT("There is currently no requirement for a held > btree conglomerate controller."); > A simple test program is attached which reproduces this failure. It fails in > the trunk and on the 10.1.2.1 release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
