XA and non XA

You have two choices about the type of DataSource, XADataSource or non-XADataSource. See the following differences.

An XA transaction can be defined as a global transaction because it can work on multiple resources. Unlike the XA transaction, a non-XA transaction always works on one resource.
An XA transaction works on a transaction manager that coordinates one or more databases (or different resources, such as JMS) all inside one global transaction. Non-XA transactions often called local transactions also don't need a transaction coordinator because a single resource makes all transaction work itself.

The X/Open group specification defines the XA transactions on distributed and global transactions. Java Transaction API (JTA) supports this specification, in a  form adapted to Java and DataSources.
XA transactions are not often used but they are very important when you must coordinate more resources in the same time. You could need to coordinate two or more databases more than just one connection or other JCA resources all together. If one of these resources fails by some accident, all the operations come back with a rollback, otherwise the commit will update all resources.

The protocol used by the Transaction Manager coordinator that we have described is called Two Phase Commit or 2PC. It's important this protocol also is supported by the individual resources as the databases and other external resources, else the 2PC doesn't work.

An XA DataSource is a particular DataSource that participates in an XA global transaction. WildFly supports it through Ironjacamar, the official JCA resource adapter implementation and Narayana, the transaction manager implementation in WildFly.  A non-XA DataSource can't participate in a global transaction because it will not be read by the transaction manager coordinator.