Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <198965727.1223500184322.JavaMail.jira@brutus>
Date: Wed, 8 Oct 2008 14:09:44 -0700 (PDT)
From: "Myrna van Lunteren (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3875) Derby cannot replace a database after
 encountering corruption
In-Reply-To: <694242039.1221207944864.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Myrna van Lunteren updated DERBY-3875:
--------------------------------------

    Attachment: DERBY-3875_2.diff

Attached is a patch that combines elements from Jason's original patch, most of Kristian's test, and some additions/modifications:
- as discussed, the original fix didn't stop the error from occurring with sane builds; adding a RuntimeException catch block to closeContainer() in fixed that.
- modified Kristian's test so it runs with JSR169:
   - copied StringUtil's split method to junit.Utilities and use that instead of the String.split method which isn't available in jclFoundation/j2ME
     (didn't want to use StringUtil.split as I worried about that possibly changing the build order or affecting what goes in the derbyTesting.jar)
   - used datasources to get the connection instead of DriverManager
- added the test to tests.store._Suite

I ran the new BackupRestoreTest on windows with insane and sane builds with ibm's j9-jclFoundation and jdk15, store._Suite on windows (insane build) with jdk15, j9-jclFoundation and ibm16, and all looks good. I'm running suites.All for good measure on linux - if this all looks good, I can check it in...

> Derby cannot replace a database after encountering corruption
> -------------------------------------------------------------
>
>                 Key: DERBY-3875
>                 URL: https://issues.apache.org/jira/browse/DERBY-3875
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.4.2.0
>         Environment: ------------------ Java Information ------------------
> Java Version:    1.6.0_06
> Java Vendor:     Sun Microsystems Inc.
> Java home:       C:\Program Files\Java\jre1.6.0_06
> Java classpath:  C:\Working\Derby-fileclose-fix\bin;C:\Working\Derby-fileclose-fix\lib\derby.jar
> OS name:         Windows XP
> OS architecture: x86
> OS version:      5.1
> Java user name:  Administrator
> Java user home:  C:\Documents and Settings\Administrator
> Java user dir:   C:\Working\Derby-fileclose-fix
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\Working\Derby-fileclose-fix\lib\derby.jar] 10.4.2.0 - (689064)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> ------------------------------------------------------
>            Reporter: Jason McLaurin
>         Attachments: derby-3875-BackupRestoreTest.diff, derby-3875-BackupRestoreTest.stat, DERBY-3875_2.diff, DERBY-3875_tst1.diff, FileCloseBugDemo.java, FileCloseBugDemo.java, RAFContainerPatch.txt
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When Derby encounters a corrupt data file, it does not close the data file before throwing an exception to the caller.  If the user tries to replace the database with a backup in response to the corruption, Derby will first attempt to delete the contents of the corrupt database.  But since the corrupt file was never closed, it cannot be deleted, and Derby fails to start.
> The attached java code should reproduce the problem, and the attached patch should fix it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.