[
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 transaction.
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: 10.11.1.3, 10.12.0.0
> 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
(v6.3.4#6332)
