db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1058) derby fails supporting holdable scrollable resultset: ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed.
Date Wed, 15 Mar 2006 20:46:02 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1058?page=comments#action_12370581 ] 

Andreas Korneliussen commented on DERBY-1058:
---------------------------------------------

>  Comment by Mike Matrigali [28/Feb/06 10:24 PM]
..
>Btree's can under go some major changes when there are no locks. 

I do not see how locking is an issue, since BackingStoreHashTable uses temporary tables. Could
anyone explain why the proposed patch would not work in terms of BackingStoreHashTable.
Note that if this issue does not get fixed, Derby has a major bug in scrollable holdable forward
only resultsets, and it will not be possible to support holdable updatable resultsets.
I would suggest that this patch is reviewed, and if further work is needed to support holdable
Btrees in general in Derby, it could be done in another jira.

> 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: DERBY-1058.diff, DERBY-1058.stat, DERBY-1058v2.diff, DERBY-1058v2.stat,
HoldabilityIssue.java, derbyall_report.txt
>
> 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:
> ak136785@khepri35:/<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)
> ak136785@khepri35:/<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


Mime
View raw message