Preventing the "The data present in your database is newer than the version of JIRA you are trying to startup." using a Database Lock

Symptom

Attempting to startup JIRA presents the following error:

****************************************************************************************************
Failed to start JIRA due to a build number inconsistency.
The data present in your database is newer than the version of JIRA you are trying to startup.
Database version is: 6096
JIRA app version is: 733
Please use the correct version of JIRA. You are running: 5.0.6#733-sha1:f48fab7a0abaa0a316c14a3fc86cdf5a6805ba12
****************************************************************************************************

The build numbers will vary dependent upon the version of JIRA being used.

Cause

A test/dev/sandbox instance was started up against the same database production is using. This will trigger upgrade tasks to run and will alter the database so that it is setup for the new version. As the check is not performed at runtime, the production instance will not know this has happened until a restart is attempted, at which point the check is executed and the startup will fail.

Workaround

This can be fixed with either of the two options, after the test/dev/sandbox instance has been pointed to the correct test database.

1. Perform an emergency upgrade on the production instance to the same version as test as per Upgrading JIRA.
2. Restore an XML backup or database backup from prior to the upgrade by the test/dev/sandbox server. One can be found on the test/dev/sandbox instance under $JIRA_HOME/export/jira_autoexport_20130530_102302.zip (the naming convention will vary as it depends upon the date).

Please note that if the first option is selected the integrity of the database cannot be guaranteed, as JIRA was never designed to have multiple instances utilising the same database. This can cause critical data integrity issues that may be irreparable.

Resolution

We have seen users frequently connect their test/dev/sandbox instances to the production database accidentally.

The use case is an admin copies their $JIRA_HOME for testing, but the dbconfig.xml file is still pointing to their production database. If the dbconfig.xml file is forgotten to be altered to point at a testing database, when that server starts up it this will then fire off upgrade tasks at the production database from the testing installation if it is on a newer version.

I would like to request a database lock (maybe a table entry to the $JIRA_HOME lock file, and its pairing $JIRA_INSTALL directory, or some other method of uniquely identifying an instance) during bootup or some sort of other workaround to avoid the situation of two JIRA installs pointing at one database as this is a common occurrence.