The transaction manager coordinates the update of state via XAResource implementations, which are provided by the various resource managers. In most instances, resource managers will be databases, message queues or third-party JCA resource adapters. The list of JDBC database drivers and servers certified for use with JBoss Enterprise Web Platform can be found on the redhat.com website. In addition there is a reasonable probability of any driver that complies with the relevant standards functioning correctly. However, interpretation of the XA specification does differ from one vendor to another, as does quality of driver code. For maximum surety in transactional applications, thorough testing is essential, especially with regard to recovery behavior.

Database connection pools configured via the application server's *-ds.xml files using <xa-datasource> will automatically interact with the transaction manager. Connections obtained by looking up such datasource in JNDI and calling getConnection will automatically participate correctly in an ongoing transaction. This is the dominant use case and should be preferred where transactional guarantees for data access are required. For cases where the database cannot support XA transactions, it is also feasible to deploy a connection pool using <local-xa-datasource> Such datasources participate in the managed transaction using the last resource commit optimization (see below) and as such provide more limited transactional guarantees. Applications using this approach should be aware of the limitations and implemented accordingly. Connections obtained from a <no-tx-datasource> will not interact with the transaction manager and any work done on such connections must be explicitly committed or rolled back by the application via the JDBC API.

Many databases require additional configuration if they are to be used as XA resource managers. For example, MS SQL Server requires configuration of the DTC service and installation of a server side component of the JDBC drivers. Some versions of Oracle similarly require a server side package to be installed in the database instance. PostgreSQL installations may require an alteration to the number of outstanding transactions they permit the default is normally too low for production usage. MySQL has significant limitations on its XA implementation and is not recommended for use in an XA transaction. If it is used, the InnoDB storage engine must be configured. Please consult your database administrator or database documentation for further product-specific information. In addition, it is important to take any further database configuration steps needed to support XA recovery, see the recovery section below.