MULESOFT-INTEGRATION-ARCHITECT-I practice question 3 of 10

A Mule application is being designed to do the following: Step 1: Read a SalesOrder message from a JMS queue, where each SalesOrder consists of a…

Choose your answer, then check it against the explanation.

A Mule application is being designed to do the following: Step 1: Read a SalesOrder message from a JMS queue, where each SalesOrder consists of a header and a list of SalesOrderLineltems. Step 2: Insert the SalesOrder header and each SalesOrderLineltem into different tables in an RDBMS. Step 3: Insert the SalesOrder header and the sum of the prices of all its SalesOrderLineltems into a table In a different RDBMS. No SalesOrder message can be lost and the consistency of all SalesOrder-related information in both RDBMSs must be ensured at all times. What design choice (including choice of transactions) and order of steps addresses these requirements?

Answer options

Correct Answer:

Explanation

The scenario requires ensuring data consistency across three different transactional resources: a JMS queue and two separate RDBMS instances. This is a classic use case for a distributed transaction. An XA (eXtended Architecture) transaction coordinates multiple resources in a single, atomic unit of work. By wrapping the JMS read and both database inserts within the same XA transaction, the system guarantees that either all operations succeed (commit) or all are rolled back if any single operation fails. This prevents message loss and ensures the two databases remain consistent with each other.

Why Incorrect

A. A single DB transaction cannot span two different RDBMS instances. Also, if the DB insert fails, the JMS message might be lost if acknowledged separately.

B. Using separate DB transactions breaks atomicity. If the first DB insert succeeds but the second fails, the data becomes inconsistent across the two RDBMSs.

D. Acknowledging the JMS message before the database transactions means the message is permanently removed from the queue. If the subsequent XA transaction fails, the message is lost.

References

1. MuleSoft Documentation, "Transactions in Mule Applications". This document explains that "XA transactions are transactions that can span across multiple transactional resources". It details how to configure a flow with a JMS listener and multiple database connectors to participate in a single XA transaction to ensure data integrity. (See section on "XA Transactions").

2. MuleSoft Documentation, "JMS Connector - Mule 4 > Transactions". This page states: "To have a JMS transaction and a database transaction in the same transaction, you must use an XA transaction". This directly supports the need for XA in this scenario.

Question 3 of 10

Keep practicing

Take the free MULESOFT-INTEGRATION-ARCHITECT-I practice test

Ten exam-style questions with answers and explanations, plus the exam facts and study guides.

Start the free practice test