Reliability patterns without distributed transactions
Get zero message loss without XA: a reliability pattern behind nontransactional sources, an endpoint that survives the deployment, safe file and FTP handling, a local transaction plus a redelivery-tolerant write (design reasoning, not a documented Mule feature), and Batch Job record-level failure handling.
Select alternatives to traditional transactions (local or XA) where appropriate and beneficial.
~8 min read · 5 practice questions
What the exam expects
- Recognize when a nontransactional source (HTTP, File, FTP) rules out a transaction and a reliability pattern is the alternative.
- Choose the transactional endpoint for a reliable acquisition flow from the deployment (standalone or clustered) and the software available.
- Configure resource-based sources so a file is not lost when processing fails in another flow.
- Replace an XA transaction with a Single Resource transaction when throughput matters more than two-phase commit, and plan for redelivered messages.
- Replace one all-or-nothing transaction over a large data set with Batch Job record-level failure handling.
Reliability pattern: a design that couples a reliable acquisition flow with an application logic flow so messaging stays reliable even from a nontransactional connector. Reliable acquisition flow: the flow that moves a message from a nontransactional source to a transactional outbound operation. Single Resource (local) transaction: a transaction over one resource and one connector configuration. XA transaction: a global transaction coordinated with two-phase commit across several resources (Reliability Patterns, Transaction Management). Idempotent write (Exam convention, design reasoning): a write that is safe to repeat without a duplicate effect. Message de-duplication: letting only messages with a unique ID continue through a flow (Idempotent Message Validator).
Key facts
- Detail
- Return an unsuccessful-request response so the client retries.
- Detail
- No extra software; non-clustered environments only.
- Detail
- Clustered and non-clustered; requires a message queue server.
- Detail
- Can lose messages; not considered reliable.
- Detail
watermarkEnabled="true"; noauto-deleteormoveToDirectory.
- Detail
- Same connector and same
config-ref; no nested transactions.
- Detail
- Two-phase commit latency and an external transaction manager.
- Detail
- Idempotent Message Validator raises
MULE:DUPLICATE_MESSAGE.
- Detail
- Not part of it; records use internal batch transactions.
maxFailedRecords values- Detail
0default stop,-1never stop, integer threshold.
acceptPolicy- Detail
NO_FAILURESdefault;ONLY_FAILURES;ALL.
Sources for this section (7)
- Reliability Patternsdocs.mulesoft.com (opens in a new tab)
- Transaction Managementdocs.mulesoft.com (opens in a new tab)
- Single Resource Transactionsdocs.mulesoft.com (opens in a new tab)
- XA Transactionsdocs.mulesoft.com (opens in a new tab)
- Idempotent Message Validatordocs.mulesoft.com (opens in a new tab)
- Handling Errors During Batch Jobdocs.mulesoft.com (opens in a new tab)
- Configuring Batch Componentsdocs.mulesoft.com (opens in a new tab)
- Why does Mule, at the default log level, log a batch error only the first time it appears in a step?
- When does an FTP-to-VM acquisition flow need a max redelivery count?
- What does
Batch::getStepErrors()return for a record that has not failed in any step?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the MuleSoft Platform Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 40 lessons of the MuleSoft Platform Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Practice exams purchase adds inline bank questions and topic practice (5 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Choose guide-only, practice-only, or save $4 with both