db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5679) Rolling back a transaction leads to an inconsistent state
Date Wed, 25 Apr 2012 18:56:19 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261946#comment-13261946
] 

Mike Matrigali commented on DERBY-5679:
---------------------------------------


I think the approach of getting update to log nulls in this case is a good one.  Store is
going to be broken if non-existent columns are 
anywhere other than at the end of the row.  Changing non-existent columns to null valued columns
at update time seems like a good
approach.

Is the code you are changing happening because the user update is updating column N with a
value,  column N-1 and N were
added because of add column and neither has ever had a real value.  And this trip through
log column is dealing with column N-1.

I think it might be cleaner if you just add another if/then/else just for COLUMN_NULL at line
6306, rather than code the case of a real
column and a nonexistent column in same case.  I think sColumn is null for your case in this
and found it confusing, seems like
the code works by accident not referencing the null pointer, so someone later could easily
use it thinking it was valid.

The code for COLUMN_NULL is much simpler as it just knows it is creating a NULL value out
of the ether.  

nits:
o could you make the code be 80 column 
o I think a different name might be better, maybe COLUMN_CREATENULL.  I kept seeing the COLUMN_NULL
name and thinking it
   was an existing null column, which is a different code path.
o could you add comments to logColumn to say what the new option is doing.
o a good case to add but does not need to hold up your checkin would be both regular row and
long row case.  Something like
    add 100 columns, update 50th column, check you can retrieve all 100, abort check you can
retrieve all as expected.  Another row
    do 50th update and then 99th update....   The long row case comes when you make all this
work happen on second page vs
    first, so for 2k pages something like following:
    create table with real columns to fill most of a page.  with just ddl you can add columns
of char(250) that will guarantee 250 bytes
    for any insert, or you can use clob/blob and make sure you add almost pagesize bytes.
 Then use alter to add columns.   interesting
    cases would be some nonexistent columns on first page and then an update of one that will
end up on second page or more.  




                
> 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