Talk

XA transactions

Java Technology Forums

A non-XA transaction is what you get (usually automatically) if you access JDBC connections and do statements over them. A non-XA (or local) transaction can only span one connection (if you rollback, it's the work on that connection only).

A JTA transaction is any transaction that you configure in the application server. For instance, if you use a bean with REQUIRED transaction settings in the deployment descriptor, then that will be a JTA transaction.
Same thing for UserTransaction.begin() (if you do that).

XA-compliant means that the JDBC or JCA driver you are using is compatible with the JTA transaction manager in the application server: the driver will listen to the instructions that the application server gives it to rollback or commit. non-XA-compliant JDBC or JCA drivers don't listen to this and do what they want.

Indeed, the tricky part is when you combine e.g. JDBC and JTA transactions: if you're not careful then the JDBC will still use its own,"separate" local (non-XA) transaction. That is the case for non-XA-compliant drivers. The effect is that when the application server calls rollback() then this will not be done properly. Simply because the application server is unable to rollback your "local, non-XA" transactions. This is not what you want and that's why the application server warns you.

XA
XA and weblogic

X/Open Distributed Transaction Processing (DTP) XA interface

TPMs: (Transaction Processing Monitors): Tuxedo, CICS, NCR TopEnd, UniKix