Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 4590 invoked from network); 13 Apr 2011 13:55:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Apr 2011 13:55:44 -0000 Received: (qmail 54140 invoked by uid 500); 13 Apr 2011 13:55:44 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 54122 invoked by uid 500); 13 Apr 2011 13:55:44 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 54115 invoked by uid 99); 13 Apr 2011 13:55:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Apr 2011 13:55:44 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Apr 2011 13:55:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id D22149FADB for ; Wed, 13 Apr 2011 13:55:05 +0000 (UTC) Date: Wed, 13 Apr 2011 13:55:05 +0000 (UTC) From: "Knut Anders Hatlen (JIRA)" To: derby-dev@db.apache.org Message-ID: <544058878.54987.1302702905857.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (DERBY-2354) Unable to perform select query using DISTINCT on a read-only database MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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/%3C20957328.post@talk.nabble.com%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.(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.(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