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 B342C91B5 for ; Tue, 24 Apr 2012 12:37:56 +0000 (UTC) Received: (qmail 19972 invoked by uid 500); 24 Apr 2012 12:37:56 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 19912 invoked by uid 500); 24 Apr 2012 12:37:56 -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 19902 invoked by uid 99); 24 Apr 2012 12:37:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Apr 2012 12:37:56 +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; Tue, 24 Apr 2012 12:37:55 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id EC16140C085 for ; Tue, 24 Apr 2012 12:37:34 +0000 (UTC) Date: Tue, 24 Apr 2012 12:37:34 +0000 (UTC) From: "Rick Hillegas (JIRA)" To: derby-dev@db.apache.org Message-ID: <980608405.9194.1335271054972.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <393514197.34622.1333052542016.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (DERBY-5679) Rolling back a transaction leads to an inconsistent state MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260472#comment-13260472 ] Rick Hillegas commented on DERBY-5679: -------------------------------------- >My assumption is that the problem is either the log record written out is bad, or the recovery process on the log record is bad. Can you tell from debugging which so far? I think that the suspect code is being called in the former case. But I could be pursuing a red herring--as you say, this code is intricate. Thanks. > Rolling back a transaction leads to an inconsistent state > --------------------------------------------------------- > > Key: DERBY-5679 > URL: https://issues.apache.org/jira/browse/DERBY-5679 > Project: Derby > Issue Type: Bug > Components: Store > Affects Versions: 10.6.2.1, 10.8.2.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\jre7\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.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.2.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.2.2-bin\lib\derby.jar] 10.8.2.2 - (1181258) > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbytools.jar] 10.8.2.2 - (1181258) > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbynet.jar] 10.8.2.2 - (1181258) > [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbyclient.jar] 10.8.2.2 - (1181258) > ------------------------------------------------------ > ----------------- Locale Information ----------------- > Current Locale : [English/New Zealand [en_NZ]] > Found support for locale: [cs] > version: 10.8.2.2 - (1181258) > Found support for locale: [de_DE] > version: 10.8.2.2 - (1181258) > Found support for locale: [es] > version: 10.8.2.2 - (1181258) > Found support for locale: [fr] > version: 10.8.2.2 - (1181258) > Found support for locale: [hu] > version: 10.8.2.2 - (1181258) > Found support for locale: [it] > version: 10.8.2.2 - (1181258) > Found support for locale: [ja_JP] > version: 10.8.2.2 - (1181258) > Found support for locale: [ko_KR] > version: 10.8.2.2 - (1181258) > Found support for locale: [pl] > version: 10.8.2.2 - (1181258) > Found support for locale: [pt_BR] > version: 10.8.2.2 - (1181258) > Found support for locale: [ru] > version: 10.8.2.2 - (1181258) > Found support for locale: [zh_CN] > version: 10.8.2.2 - (1181258) > Found support for locale: [zh_TW] > version: 10.8.2.2 - (1181258) > ------------------------------------------------------ > Reporter: Brett Mason > Priority: Critical > Attachments: RollbackFails - expected output.txt, RollbackFails.sql, derby-5679-01-aa-alterTableTouchAllRows.diff > > > Rolling back a transaction can leave a table in an inconsistent state if the table has been previously altered through the addition of new columns. It appears that if newly added columns have not been changed from their default value, then when a transaction which sets new values for these columns is rolled back the new columns are not restored to their previous values. > Attached is an ij script with fairly minimal steps to reproduce the problem on Derby 10.6.2.0 and 10.8.2.2 (Win7 x64, Sun 32-bit JRE 1.6.0.26). Expected and observed output also attached. > Would appreciate any suggestions as to a workaround for this issue. Running SYSCS_UTIL.SYSCS_COMPRESS_TABLE on the table after adding the columns seems to avoid the problem but may be just masking the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira