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-6797) If a (machine/jvm) crash happens during hard upgrade, derby does not roll back the upgrade.
Date Wed, 04 Mar 2015 18:59:38 GMT

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

Mike Matrigali commented on DERBY-6797:

To debug I would suggest setting properties such that derby.log is always appended to.  Then
turn on log
statement text and run through your repro.  The first thing I would be looking for is to see
if we execute the
upgrade in more than one transaction.  

I think the only way it is only going to work is if all hard upgrade stuff is done as a single

The next thing would be to see if any part of a hard upgrade is not transactional.  Anything
that manipulates the 
database should be.  Wonder if there is anything that updates a property file rather than
use the database properties that are maintained in a table?

> If a (machine/jvm) crash happens during hard upgrade, derby does not roll back the upgrade.
> -------------------------------------------------------------------------------------------
>                 Key: DERBY-6797
>                 URL: https://issues.apache.org/jira/browse/DERBY-6797
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,
>            Reporter: Myrna van Lunteren
>         Attachments: AfterUpgrade.java, DERBY-6797.diff, HardUpgradeAbort.java, Prepare4Upgrade.java
> When a crash happens during hard upgrade of derby, the upgrade -up to that point - is
not rolled back. Depending on where the crash happens this might leave a broken database behind.
> This makes it extra important to create a backup before doing a hard upgrade.
> I have not tested this with a soft upgrade.
> I will attach a test case which uses the upgrade test suite framework and uses a call
of SanityManager.DEBUG_SET("upgrade_abort") to send a flag, and a change in impl/sql/catalog/DD_version
to listen for this flag.
> Thus, it's only a test that would run in a sane environment.
> But this test does show that even if we see the error during hard upgrade, the resulting
database appears to be in the newer version. I have manually tested this with 10.11 (by modifying
DD_version in 10.11 to throw the error regardless of sanity manager or not) and with 10.12
by running my new test.

This message was sent by Atlassian JIRA

View raw message