In MariaDB, the term "XA transactions" has traditionally been overloaded to mean two different things:

• The first type is known as "external", "client", or "statement-driven" XA transactions - These are transactions that use the client two-phase commit interface, which uses SQL statements like XA START, XA PREPARE, XA COMMIT, etc. When most MariaDB users hear"XA transactions", this is probably the type that they're more likely to think of.
• The second type is known as "internal", "server", or "binlog-driven" XA transactions - These are transactions that go through the server's two-phase commit API. With this API, the storage engine prepares and commits these transactions in separate steps.

There's more information here:

https://mariadb.com/kb/en/xa-transactions/#internal-xa-vs-external-xa

Overloading terms like this causes a lot of confusion, especially when diagnosing bug reports that involve XA transactions. We could benefit quite a bit by changing terminology.

It probably makes sense for "external" XA transactions to be associated with the term "XA transactions", because the statements are prefixed with "XA" and because most users probably already know of them as "XA transactions".

It might make sense for "internal" XA transactions to be called something else. What should we call them? Some ideas:

• Prepared transactions? It is pretty accurate, but it might be mistaken for prepared statements.
• Binlog-driven transactions?
• 2-phase commit (2PC) transactions?

If we decide to split these two concepts into separate terms, then we should remove or clarify log messages that refer to "XA transactions".

For example, when InnoDB and the binlog/transaction coordinator log (tclog) discover uncommitted external or internal transactions at startup, they log messages like this:

2020-01-15 20:49:38 0 [Note] InnoDB: Starting recovery for XA transactions...

2020-01-15 20:49:38 0 [Note] InnoDB: Transaction 351782717 in prepared state after recovery

2020-01-15 20:49:38 0 [Note] InnoDB: Transaction contains changes to 3 rows

2020-01-15 20:49:38 0 [Note] InnoDB: 1 transactions in prepared state after recovery

2020-01-15 20:49:38 0 [Note] Found 1 prepared transaction(s) in InnoDB

2020-01-15 20:49:38 0 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.

2020-01-15 20:49:38 0 [ERROR] Aborting

For log messages like this, we should probably clarify them in the following way:

• If a log message can refer to either "external" or "internal" XA transactions, then we should probably change the log message to mention both terms, like:

2020-01-15 20:49:38 0 [Note] InnoDB: Starting recovery for uncommitted XA transactions and uncommitted 2PC transactions...

• If a log message can only refer to "external" XA transactions, then it should be fine to continue using the term "XA transactions".

• If a log message can only refer to "internal" XA transactions, then the log message should use the new term.