How to Handle Single and XA (Extended Architecture) Transactions in MuleSoft
"Transaction" is a word that is used way too frequently in our daily lives. We use it whenever we are engaged in purchasing or selling any commodity. In our daily lives, a transaction signifies an instance of buying or selling something. Also, a transaction can be deemed as completed only upon the overall completion of the buying/selling activity along with the monetary affair associated with it.
In the software industry, we use the word ‘transaction’ in multiple areas. Predominantly, it is used while discussing SQL queries. Transactions make up a very important component of any software development life cycle (SDLC). Let’s see how transactions are changing lives!
A transaction is a group of operations where all the steps are needed to be successful to commit a result. If any one of the intermediate steps fail, the whole chain of steps fails collectively.
Let’s understand it using a pictorial reference.
Let’s consider a case where we have a chain of steps that represents the following:
Step | Action | Table involved |
|---|---|---|
Step 1 | This is a SQL fetch operation that fetches information on a certain deal | Table A |
Step 2 | This is a SQL insert operation that inserts the new record after consolidating the data received in the previous step | Table A |
Step 3 | This is a SQL delete operation that deletes the previously available record | Table A |
Step 4 | This is a SQL update operation that updates the amount update in another table | Table B |
We want all the steps to be completed collectively or else we want none of them to happen. In layman’s terms, we want the event to be committed only if all the steps are successful. If any intermediate step fails, we do not want the event to be committed and we do not want any step to be actioned upon.
In the above picture, we have encapsulated these 4 steps in a transaction. The first diagram starts and completes without any errors and gets committed.
But in the second diagram, we can see that in step 2 we encountered a certain error. Now, we don’t want the event to be committed. This is made possible by the transaction action. It will make sure that all the steps are rolled back to the initial state from which the event was kicked off.
Now that we are clear on what transaction is and how it helps in software development, let’s indulge ourselves in bringing it to life in MuleSoft.
MuleSoft supports two types of transactions:
Single resource
XA transactions (Extended Architecture)
Let's talk about them in detail.
Single Resource transactions
Let's consider a Mule flow where we are dealing with a single mode of data transaction. Consider our flow is having only JDBC affairs or JMS activities or VM Queues.
We have created a flow in which we are dealing with 2 tables connecting to the same database. This is how the flow looks like:
