Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4154C797B for ; Mon, 25 Jul 2011 00:23:35 +0000 (UTC) Received: (qmail 22592 invoked by uid 500); 25 Jul 2011 00:23:34 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 22043 invoked by uid 500); 25 Jul 2011 00:23:34 -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 21491 invoked by uid 99); 25 Jul 2011 00:23:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2011 00:23:33 +0000 X-ASF-Spam-Status: No, hits=-2001.2 required=5.0 tests=ALL_TRUSTED,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; Mon, 25 Jul 2011 00:23:32 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 7A83983823 for ; Mon, 25 Jul 2011 00:23:11 +0000 (UTC) Date: Mon, 25 Jul 2011 00:23:11 +0000 (UTC) From: "Brett Mason (JIRA)" To: derby-dev@db.apache.org Message-ID: <1402682769.2578.1311553391481.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <381326834.2573.1311553283178.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (DERBY-5351) SYSCS_UTIL.SYSCS_COMPRESS_TABLE causes concurrent transactions to fail 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-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Mason updated DERBY-5351: ------------------------------- Description: Our application is set to run a set of nightly maintenance tasks which include SYSCS_UTIL.SYSCS_COMPRESS_TABLE. From our logs it appears that occasionally selects will fail while the database is being compressed with the following error: "ERROR XSCH1: Container 1,408 not found." A full stack trace is included below. Attached is a standalone test case which will reproduce the problem within a couple of seconds. It will create two threads, one which will repeatedly compress TABLE1 while the second thread tries to read from the table. The documentation states that SYSCS_COMPRESS_TABLE will acquire an exclusive lock on the table which suggests it any simultaneous requests should block until the compress has completed. A workaround is to switch to SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE which does not seem to have the problem. Sample output from test case --------------------------------------- Thread-3: Selecting... Thread-2: Compressing... Thread-3: Selecting... Thread-3: Selecting... Thread-2: Compressing... Thread-3: Selecting... Thread-3: Selecting... Thread-3: Selecting... Thread-2: Compressing... Thread-3: Selecting... Thread-2: Compressing... java.sql.SQLException: Container 2,480 not found. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source) at BashOnCompressTables$SelectRunnable.select(BashOnCompressTables.java:67) at BashOnCompressTables$SelectRunnable.run(BashOnCompressTables.java:48) at java.lang.Thread.run(Unknown Source) Caused by: java.sql.SQLException: Container 2,480 not found. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 12 more Caused by: ERROR XSCH1: Container 2,480 not found. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.openScan(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openCompiledScan(Unknown Source) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openScanController(Unknown Source) at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 6 more was: It appears that Derby simultaneous requests to a table which is being compressed with SYSCS_UTIL.SYSCS_COMPRESS_TABLE will sometimes fail. Our application is set to run a set of nightly maintenance tasks which include SYSCS_UTIL.SYSCS_COMPRESS_TABLE. From our logs it appears that occasionally selects will fail while the database is being compressed with the following error: "ERROR XSCH1: Container 1,408 not found." A full stack trace is included below. Attached is a standalone test case which will reproduce the problem within a couple of seconds. It will create two threads, one which will repeatedly compress TABLE1 while the second thread tries to read from the table. The documentation states that SYSCS_COMPRESS_TABLE will acquire an exclusive lock on the table which suggests it any simultaneous requests should block until the compress has completed. A workaround is to switch to SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE which does not seem to have the problem. Sample output from test case --------------------------------------- Thread-3: Selecting... Thread-2: Compressing... Thread-3: Selecting... Thread-3: Selecting... Thread-2: Compressing... Thread-3: Selecting... Thread-3: Selecting... Thread-3: Selecting... Thread-2: Compressing... Thread-3: Selecting... Thread-2: Compressing... java.sql.SQLException: Container 2,480 not found. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source) at BashOnCompressTables$SelectRunnable.select(BashOnCompressTables.java:67) at BashOnCompressTables$SelectRunnable.run(BashOnCompressTables.java:48) at java.lang.Thread.run(Unknown Source) Caused by: java.sql.SQLException: Container 2,480 not found. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 12 more Caused by: ERROR XSCH1: Container 2,480 not found. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.openScan(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openCompiledScan(Unknown Source) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openScanController(Unknown Source) at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 6 more > SYSCS_UTIL.SYSCS_COMPRESS_TABLE causes concurrent transactions to fail > ---------------------------------------------------------------------- > > Key: DERBY-5351 > URL: https://issues.apache.org/jira/browse/DERBY-5351 > Project: Derby > Issue Type: Bug > Affects Versions: 10.6.2.1, 10.8.1.2 > Environment: >sysinfo > ------------------ Java Information ------------------ > Java Version: 1.6.0_26 > Java Vendor: Sun Microsystems Inc. > Java home: C:\Program Files (x86)\Java\jre6 > Java classpath: .;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\bin\../lib/derbytools.jar > OS name: Windows 7 > OS architecture: x86 > OS version: 6.1 > Java user name: bmason > Java user home: C:\Users\BMASON > Java user dir: C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\bin > java.specification.name: Java Platform API Specification > java.specification.version: 1.6 > java.runtime.version: 1.6.0_26-b03 > --------- Derby Information -------- > JRE - JDBC: Java SE 6 - JDBC 4.0 > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\lib\derby.jar] 10.8.1.2 - (1095077) > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\lib\derbytools.jar] 10.8.1.2 - (1095077) > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\lib\derbynet.jar] 10.8.1.2 - (1095077) > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.1.2-bin\lib\derbyclient.jar] 10.8.1.2 - (1095077) > ------------------------------------------------------ > ----------------- Locale Information ----------------- > Current Locale : [English/New Zealand [en_NZ]] > Found support for locale: [cs] > version: 10.8.1.2 - (1095077) > Found support for locale: [de_DE] > version: 10.8.1.2 - (1095077) > Found support for locale: [es] > version: 10.8.1.2 - (1095077) > Found support for locale: [fr] > version: 10.8.1.2 - (1095077) > Found support for locale: [hu] > version: 10.8.1.2 - (1095077) > Found support for locale: [it] > version: 10.8.1.2 - (1095077) > Found support for locale: [ja_JP] > version: 10.8.1.2 - (1095077) > Found support for locale: [ko_KR] > version: 10.8.1.2 - (1095077) > Found support for locale: [pl] > version: 10.8.1.2 - (1095077) > Found support for locale: [pt_BR] > version: 10.8.1.2 - (1095077) > Found support for locale: [ru] > version: 10.8.1.2 - (1095077) > Found support for locale: [zh_CN] > version: 10.8.1.2 - (1095077) > Found support for locale: [zh_TW] > version: 10.8.1.2 - (1095077) > ------------------------------------------------------ > Reporter: Brett Mason > Attachments: CompressTableTestCase.java > > > Our application is set to run a set of nightly maintenance tasks which include SYSCS_UTIL.SYSCS_COMPRESS_TABLE. From our logs it appears that occasionally selects will fail while the database is being compressed with the following error: "ERROR XSCH1: Container 1,408 not found." A full stack trace is included below. > Attached is a standalone test case which will reproduce the problem within a couple of seconds. It will create two threads, one which will repeatedly compress TABLE1 while the second thread tries to read from the table. The documentation states that SYSCS_COMPRESS_TABLE will acquire an exclusive lock on the table which suggests it any simultaneous requests should block until the compress has completed. > A workaround is to switch to SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE which does not seem to have the problem. > Sample output from test case > --------------------------------------- > Thread-3: Selecting... > Thread-2: Compressing... > Thread-3: Selecting... > Thread-3: Selecting... > Thread-2: Compressing... > Thread-3: Selecting... > Thread-3: Selecting... > Thread-3: Selecting... > Thread-2: Compressing... > Thread-3: Selecting... > Thread-2: Compressing... > java.sql.SQLException: Container 2,480 not found. > at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) > at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source) > at BashOnCompressTables$SelectRunnable.select(BashOnCompressTables.java:67) > at BashOnCompressTables$SelectRunnable.run(BashOnCompressTables.java:48) > at java.lang.Thread.run(Unknown Source) > Caused by: java.sql.SQLException: Container 2,480 not found. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) > ... 12 more > Caused by: ERROR XSCH1: Container 2,480 not found. > at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) > at org.apache.derby.impl.store.access.heap.Heap.openScan(Unknown Source) > at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) > at org.apache.derby.impl.store.access.RAMTransaction.openCompiledScan(Unknown Source) > at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openScanController(Unknown Source) > at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown Source) > at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown Source) > at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) > ... 6 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira