All the resources joined to a two-phase commit transaction must be a XA compliant resource, so they must support the X/Open XA distributed transaction protocol shown in the previous section Distributed transactions and JTA. But there are cases where the resources don't support the XA protocol. How does it do it in these cases? There are workarounds for it.

Some databases don't support a XA connection so could happen to have a non-XA resource in its own distributed XA transaction. In these cases, the resource could work anyway because the transaction manager could emulate the XA operation passing them as successful. The problem is when the non-XA resource throws an error. In this case, the XA transaction manager is not unable to understand the error, so an inconsistent state could happen. Always take extra care about these cases. An important thing is to establish a priority to the used resources. For example, when you project the application, a non-XA database has no sense to manage important data.

Some emulating transaction managers could add restrictions on their support for this, such as allowing only one non-XA resource to join in a distributed XA transaction.