db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5679) Rolling back a transaction leads to an inconsistent state
Date Tue, 24 Apr 2012 17:43:33 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-5679:
---------------------------------

    Attachment: derby-5679-01-ab-storedPageChange.diff

Attaching derby-5679-01-ab-storedPageChange.diff. This second approach changes update code
in StoredPage. I am not an expert in this area and am not confident that this is the correct
fix. The patch, however, does satisfy three useful conditions:

1) It makes the repro run correctly.

2) It doesn't break any of our existing regression tests.

3) It is small.

Let me explain what I did.

I started out being suspicious of the first update in the repro, the one whose comment suggested
that it was making a crucial change which set up the bug:

--This update is important.
UPDATE TABLE1 SET STR2 = 'before2';

I noticed that the value for one of the other columns became correct after the rollback if
the "important" update was followed by another update which explicitly set the other new column
to null:

-- this fixes the problem
update TABLE1 set str1 = null;

This suggested that the bug could at least be patched over by forcing the other new columns
to be null during the "important" update.

Tracing through the code, I noticed that during the "important" update, the untouched columns
took an unusual trajectory through the StoredPage.logRow() pinball machine. There they fell
into this code block at line 3970. The block appears to have puzzled other people:

                        // this is an update that is increasing the number of 
                        // columns but not providing any value, strange ...

                        spaceAvailable = 
                            logColumn(
                                null, 0, out, spaceAvailable, 
                                columnFlag, overflowThreshold);

I fixed this case by inventing a new column flag to tell StoredPage.logColumn() that it should
write a null column, rather than a nonexistent one.

Would appreciate your thoughts about this approach.


Touches the following files:

------------

M       java/engine/org/apache/derby/impl/store/raw/data/StoredPage.java

The fix.

------------

M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/AlterTableTest.java

Regression test case.

                
> 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,
derby-5679-01-ab-storedPageChange.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

        

Mime
View raw message