Background

When Confluence starts up, it verifies schemas for all tables with active objects (AO), and modifies / adds fields if required. For example, if a new version of a plugin is installed, and this plugin introduces a new field in AO class, the corresponding table will be updated and new column will be created.

The problem

For MySQL, migration procedure has a bug and updates several tables on every boot like this:

 [[SQLAction{statement='ALTER TABLE AO_BAF3AA_AOINLINE_TASK CHANGE COLUMN BODY BODY LONGTEXT DEFAULT NULL', undoAction=null}]]


[[SQLAction{statement='ALTER TABLE AO_88BB94_BATCH_NOTIFICATION CHANGE COLUMN PAYLOAD PAYLOAD LONGTEXT NOT NULL', undoAction=null}]]


[[SQLAction{statement='ALTER TABLE AO_21D670_WHITELIST_RULES CHANGE COLUMN EXPRESSION EXPRESSION LONGTEXT NOT NULL', undoAction=null}]]

...etc...

It is not a serious issue for Confluence with one node (it only increases boot time), but in case of 2+ nodes it could lead Confluence to deadlock. Example:

1. The first node is executing slow query (which takes a lot of time) on AO_BAF3AA_AOINLINE_TASK table
2. The second node is being restarted and is trying to modify AO_BAF3AA_AOINLINE_TASK. But this operation is blocked while the first node does not finish all SQL queries on AO_BAF3AA_AOINLINE_TASK
3. The first node tries to run more SQL queries on AO_BAF3AA_AOINLINE_TASK, but all of them are blocked by DDL operation on the second node.

As a result, all threads could be blocked.

Expected behaviour

Confluence should not run any DDL operations on boot if tables do not require changes.

Technical details

It happens in SchemaGenerator.migrate