Vendor-Specific XA Recovery Configuration - add warning, update MySQL, update MariahDB

12.8.2. Vendor-Specific XA Recovery
Vendor-Specific Configuration

Some databases require specific configurations in order to cooperate in XA transactions managed by the JBoss EAP transaction manager. For detailed and up-to-date information, see your database vendor’s documentation. 

1) We should call this out as very important, and explain that users should consult their database vendor (documentation or support) to confirm if / which permissions are required for a database user to perform / access XA Recovery data in the database.  If you use XA (2pc / 2 phase commit datasources) for distributed transactions, and the user-name (or recovery user-name) configured in the EAP datasources subsystem for the given database(s) does not have permission on the database to perform XA-Recovery and a server instance fails during the 2 phase commit, then data integrity will be inconsistent until the configuration is fixed on the database and EAP is able to perform XA-Recovery.

2) We should indicate that we provide some known configuration required for the databases in this section, but we always recommend checking with the particular database vendor to confirm it is correct for their given database

For automated XA recovery, MySQL 8 and later requires special configuration. For more information, see the JBoss EAP 7.4 supported configurations. 

3) We mention MySQL 8 requires special configuration and point to the Support Configs, but this does not explain the configuration.  [1] indicates the configuration that would be needed.

Prior to MySQL 8.0, any user could execute the XA RECOVER statement to discover the XID values for outstanding prepared XA transactions, possibly leading to commit or rollback of an XA transaction by a user other than the one who started it. In MySQL 8.0, XA RECOVER is permitted only to users who have the XA_RECOVER_ADMIN privilege, which is expected to be granted only to administrative users who have need for it. This might be the case, for example, for administrators of an XA application if it has crashed and it is necessary to find outstanding transactions started by the application so they can be rolled back. This privilege requirement prevents users from discovering the XID values for outstanding prepared XA transactions other than their own. It does not affect normal commit or rollback of an XA transaction because the user who started it knows its XID. 

[1] https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html

MariaDB No special configuration is required. For more information, see the MariaDB documentation 

4) We should probably change this to say as of ...version... no special configuration is required, but always check the MariaDB documentation for the version.

5) We should then mention how to remove failed transactions, in the event xa-recovery cannot happen because of an issue where the database has lost the xa recovery data, this means the xa transaction cannot be recovered and the user would have to resolve the database inconsistency manually and then remove the failed transaction from the EAP transaction object store so that EAP will quit logging the WARN about the failed transaction:

Removing traces of failed transactions from the object store in JBoss EAP - https://access.redhat.com/solutions/163433