7.4. Recovery Modules

Each XA resource for which recovery is desired needs a corresponding recovery module configured in the "jta" section of jbossjta-properties.xml. Each recovery module must extend com.arjuna.ats.jta.recovery.XAResourceRecovery. We provide implementations for JDBC and JMS XA resources.

7.4.1. JDBC Recovery

JBoss Enterprise Application Platform now includes recovery auto-registration in the JCA. Thus, the AppServerJDBCXARecovery which was used in previous releases is disabled by default, and will be removed entirely from future releases of the Platform. Vendor-Specific Database Information

If Oracle is configured incorrectly, you will experience the following error in your log files:
WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
To resolve this error, be sure that the Oracle user has access to the appropriate tables to accomplish the recovery:
GRANT SELECT ON sys.dba_pending_transactions TO user;
GRANT SELECT ON sys.pending_trans$ TO user;
GRANT SELECT ON sys.dba_2pc_pending TO user;
GRANT EXECUTE ON sys.dbms_xa TO user;
The above assumes that user is the user defined to connect from JBoss to Oracle. It also assumes that either Oracle 10g R2 (patched for bug 5945463) or 11g is in use. If an unpatched version prior to 11g is used then change the last GRANT EXECUTE to:
GRANT EXECUTE ON sys.dbms_system TO user;
See the PostgreSQL documentation for instructions on enabling prepared (i.e. XA) transactions. Version 8.4-701 of PostgreSQL's JDBC driver has a bug in org.postgresql.xa.PGXAConnection which breaks recovery in certain situations. This is fixed in newer versions.
Based on http://bugs.mysql.com/bug.php?id=12161, XA transaction recovery does not appear to be possible using MySQL. This is scheduled to be addressed in MySQL 6.1. See also JBPAPP-2576 in the release notes for JBoss Enterprise Application Platform 5.
DB2 expects XAResource.recover calls only during designated resynchronization stage which occurs when application server is restarted after crash/failure. This is a design flaw in DB2, and out of the scope of this documentation.