Datasources, what, why, how?

Hope this post clarifies how a datasource works within a Java EE server and the reasons why you would need a XA Datasource when you have distributed transactions.

The origin of this post is to provide a basic understanding so that the user feels confident when to use or not to use Datasources and XA Datasources.

Example scenarios of “Should you use XA?”:

• Your JavaEE Application has to store data in two databases using a single transaction;
• Your app needs to send a JMS message and store information in the database in a single transaction;
• You want to use PVP to store the domain information from your project in a different database from the one used by jBPM to store its data;

---

Although we mention specifically WildFly, the following information applies to most Java EE application servers.

---

To execute any operation in a database, i.e. insert data, it is necessary to create a physical connection using proper credentials. This connection needs to be valid and active. Once the operation is executed, the transaction might need to be committed (or rolled back). Once completed, the connection should be destroyed. This is the cycle that applications need to do when they do not use a database connection pool. 

WildFly removes all the overhead of creating/destroying DB connections. During its startup, it opens a few connections to the configured databases. Any times the application needs to connect to the database, it just asks a valid connection to the datasource. Since the connection is already available, this is a quick operation. The DB connection is used by the application, and once finished, (when using JTA) WildFly is responsible for committing the transaction, and the connection returns to the pool.

Despite having a pool of valid connections available, and having a transaction manager to handle transactions, the Java EE app server also provides global transaction support: if a single operation involves, for example, several resources (i.e. an Oracle DB, a MongoDB, and a Kafka Topic) it is necessary that all operations succeed or all be rolled back in case of failure. This is what a XA Datasource is for.

If, for example, an application (let’s say, your business automation project) needs to store the status of a process instance in Database A, and store process data (i.e. Person information ) in Database B, this can be done in a single transaction by configuring XA properly.

The same idea is valid for scenarios which involves different kinds of interaction within a single transaction, example: messaging + database transactions + file system

If you need to guarantee that the transaction is committed in all – or none of – the sources, then, this is a scenario where you need to use XA. 🙂