Details
-
Bug
-
Resolution: Invalid
-
Medium
-
None
-
2.4.5
-
EAC
Description
When trying to upgrade QA-EAC recently, the upgrade failed with the message -
2009-06-02 00:23:01,940 FATAL [main] [atlassian.confluence.upgrade.UpgradeLauncherServletContextListener] contextInitialized Upgrade failed, application will not start: Cannot proceed with upgrade. Cluster upgrade lock ac quired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluste r. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com. com.atlassian.confluence.upgrade.UpgradeException: Cannot proceed with upgrade. Cluster upgrade lock acquired but could not successfully tag build number in the CONFVERSION table. This may because you are trying to rerun an upgrade that has failed or there are communication problems between one or more nodes in your cluster. Please zip up your logs and attach onto a support ticket at http://support.atlassian.com. at com.atlassian.confluence.upgrade.impl.DefaultUpgradeManager.permitDatabaseUpgrades(DefaultUpgradeManager.java:134)
The problem is that the CONFVERSION entry for the current build (1624 in this case) already has the pre_upgrade_version entry indicating it has been upgraded.
This will probably happen if the server is stopped or throws an exception during the upgrade. The individual upgrade tasks are wrapped in a transaction and the VersionHistoryDao is also wrapped (responsible for adding the tag). However, the DefaultUpgradeManager is not wrapped in a transaction so when it catches any exceptions during upgrade the changes it has made (using the VersionDataDao) will not be rolledback.
That's my theory anyway.