Although the XA transaction protocol is designed to provide ACID properties by using a two-phase commit protocol, it is recognized that this is not possible in all circumstances. In particular, it is occasionally necessary to have a resource manager that is not XA aware participate in the transaction. This is often the case with data stores that can't or won't support distributed transactions. For such circumstances it is possible to employ a technique variously known as the Last Resource Gambit or Last Resource Commit Optimization (LRCO). Using this technique, the one phase resource is processed last in the prepare phase of the transaction, at which time an attempt is made to commit it. If successful, the transaction log is written and the remaining resources go through the phase two commit. If the last resource fails to commit, the transaction is rolled back. Whilst this protocol allows for most transactions to complete normally, certain types of error can cause an inconsistent transaction outcome. Therefore, we recommend using this approach only when no alternative is available. Where a single <local-tx-datasource> is used in a transaction, the LRCO will be automatically applied to it. For other cases it is possible to designate a last resource by using a special marker interface. See the JBoss Transactions documentation for details.

It is not transactionally safe (or rather, it is even more unsafe) to use more than a single one-phase resource in the same transaction. For this reason JBoss Transactions treats an attempt to enlist a second such resource as an error and will terminate the transaction. This use case is most commonly found in applications migrating from JBoss Application Server 4.0.x servers, where this usage was not considered an error. Whenever possible the <local-tx-datasource> should be changed to <xa-datasource> to resolve the difficulty. Where this is not possible, the transaction manager may be configured to allow multiple last resources, although this is not recommended.