[
https://issues.apache.org/jira/browse/DERBY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-2354:
--------------------------------------
Attachment: derby-2354-1c.diff
Scrollable updatable result sets would run into problems on read-only database
when trying to update the database. Scrollable read-only result sets are
supposed to work, but as you suspected, they have the same problem with hash
tables spilling to disk. In fact, there was a thread on derby-user about it a
while ago:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200812.mbox/%[email protected]%3E
The good news is that the patch seems to fix that problem too. I've added a
test for it and uploaded a new patch (1c).
All the regression tests passed with the 1c patch.
> Unable to perform select query using DISTINCT on a read-only database
> ---------------------------------------------------------------------
>
> Key: DERBY-2354
> URL: https://issues.apache.org/jira/browse/DERBY-2354
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Environment: Reproduced in WinXP professional, Linux (Ubuntu 6.10)
> with Sun Java 5.0
> Reporter: Thomas Kelder
> Assignee: Knut Anders Hatlen
> Labels: derby_triage10_5_2
> Attachments: DerbyTest.java, d2354-createdb.sql, d2354-repro.sql,
> derby-2354-1a.diff, derby-2354-1b.diff, derby-2354-1c.diff
>
>
> It is not possible to perform queries using DISTINCT on a read-only database
> packaged in a zip file. This generates the following error:
> ERROR 40XD1: Container was opened in read-only mode.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at org.apache.derby.impl.store.raw.data.BaseContainer.use(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
> Source)
> at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.addContainer(Unknown
> Source)
> at org.apache.derby.impl.store.raw.xact.Xact.addContainer(Unknown
> Source)
> at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
> at
> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown
> Source)
> at org.apache.derby.iapi.store.access.DiskHashtable.<init>(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.store.access.btree.BTreeForwardScan.fetchRows(Unknown
> Source)
> at org.apache.derby.impl.store.access.btree.BTreeScan.fetchSet(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.<init>(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createBackingStoreHashtableFromScan(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.HashScanResultSet.openCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(Unknown
> Source)
> at DerbyTest.main(DerbyTest.java:29)
> The problem can be reproduced using the attached java program and the
> following database file:
> http://ftp2.bigcat.unimaas.nl/~thomas.kelder/derbytest/testdb.zip.
> Both the 'derby.storage.tempDirectory' and 'derby.stream.error.file'
> properties are set to writable locations, as advised in the help file.
> Also see derby-user mailing list thread:
> http://article.gmane.org/gmane.comp.apache.db.derby.user/6123
> "This appears to be a bug, possibly a regression. When I converted your
> DB to10.0 everything worked fine even when I did NOT set the properties
> for tempDirectory and error.file (hmmm..). When I switched to using the
> 10.1 or 10.2 jars and accessed the very same database the 40XD1 ERROR
> happened." (Stanley Bradbury)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
