> For the complete documentation index, see [llms.txt](https://www.pranaypourkar.co.in/the-programmers-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.pranaypourkar.co.in/the-programmers-guide/spring/spring-features/inter-service-communication/messaging-communication/activemq/message-delivery-guarantee.md). # Message Delivery Guarantee ## About Message delivery guarantees define how reliably a message broker ensures that a message sent by a producer reaches one or more consumers. In distributed systems and asynchronous messaging architectures, these guarantees are crucial to maintaining data consistency, correctness, and resilience in case of failures. ActiveMQ supports **three primary message delivery guarantees**: 1. **At-Most-Once Delivery** 2. **At-Least-Once Delivery** 3. **Exactly-Once Delivery** Each model has trade-offs between **reliability**, **performance**, and **complexity**, and the appropriate model depends on our application's consistency and throughput requirements. ## 1. At-Most-Once Delivery A message is delivered to a consumer **zero or one time**. It may be lost if a failure occurs before or during delivery, but it is never redelivered or duplicated. **Use Case:** * When **occasional message loss is acceptable** * Logging, metrics, fire-and-forget notifications * High-throughput systems that prioritize speed over reliability **Characteristics:** * Fastest of all delivery models * No built-in retry mechanism * Simplified consumer logic * Non-persistent messaging (typically) * Risk of silent message loss **ActiveMQ Configuration:** * Session Acknowledgement Mode: `AUTO_ACKNOWLEDGE` * Producer Delivery Mode: `NON_PERSISTENT` * No transactions * No redelivery policy needed **Example Behavior:** * Producer sends a message to a queue * Message is immediately considered "delivered" once handed off * If consumer fails or crashes before processing, message is **not retried** ## 2. At-Least-Once Delivery A message is delivered **one or more times** until a consumer acknowledges receipt. This ensures **no message loss**, but **duplicates may occur**. **Use Case:** * When **data loss is unacceptable**, but duplicates can be handled * Event sourcing, data ingestion, notifications * Common in most business-critical systems **Characteristics:** * Messages persist in broker until acknowledged * Redelivery happens on failure or lack of acknowledgment * Consumers must be **idempotent** (able to process duplicates safely) * Supports persistent messaging * Can be combined with redelivery policies **ActiveMQ Configuration:** * Session Acknowledgement Mode: `CLIENT_ACKNOWLEDGE` or `INDIVIDUAL_ACKNOWLEDGE` * Producer Delivery Mode: `PERSISTENT` * Redelivery Policy (can define retries, delays, etc.) **Redelivery Policy Parameters:** * `maximumRedeliveries`: Number of retry attempts before sending to dead-letter queue * `redeliveryDelay`: Time between retries * `useExponentialBackOff`: Exponential increase in delays between retries **Example Behavior:** * Producer sends a message to a queue * Consumer receives the message but crashes before acknowledging * ActiveMQ redelivers the message after a delay * The message may be delivered multiple times until successfully acknowledged ## 3. Exactly-Once Delivery A message is delivered **only once** and is **never lost or duplicated**, even in the face of system or network failures. This is the **most reliable** and **most complex** delivery model. **Use Case:** * Financial transactions, order processing, inventory updates * Any system that requires **strong consistency** and **no duplication** * Often used with transactional message processing and XA transactions **Characteristics:** * Relies on **transactions** and **commit/rollback** mechanisms * Uses `SESSION_TRANSACTED` or external distributed transaction managers (XA) * Slower performance due to two-phase commit (2PC) * Ensures atomicity: either all operations succeed or none do **ActiveMQ Configuration:** * Session Acknowledgement Mode: `SESSION_TRANSACTED` * Delivery Mode: `PERSISTENT` * Transactions must be explicitly committed * If rollback occurs, messages are redelivered * Can integrate with external transaction managers for XA compliance **XA Transactions (Distributed Transactions):** * Enables coordinating message delivery and DB updates in a single transaction * Requires additional configuration in broker and client * Uses the XA protocol to ensure exactly-once semantics across systems **Example Behavior:** * Producer sends a message as part of a transaction * Consumer receives the message and processes it * Transaction commits only if processing succeeds * If consumer crashes or rollback is issued, message remains in the queue and is redelivered ## Comparison | Guarantee | Message Loss | Duplicates | Performance | Complexity | Idempotent Consumer Required | | ------------- | ------------ | ---------- | ----------- | ---------- | ---------------------------- | | At-Most-Once | Possible | No | High | Low | No | | At-Least-Once | No | Possible | Medium | Medium | Yes | | Exactly-Once | No | No | Low | High | No | ### Message Acknowledgement Modes in JMS
ModeDescription
AUTO_ACKNOWLEDGEAutomatically acknowledges message receipt once it is received. Suitable for at-most-once.
CLIENT_ACKNOWLEDGEApplication explicitly acknowledges message. Suitable for at-least-once.
DUPS_OK_ACKNOWLEDGELazy acknowledgment. Can lead to duplicates. Rarely used.
SESSION_TRANSACTEDMessage acknowledgment is part of a JMS transaction. Suitable for exactly-once.
INDIVIDUAL_ACKNOWLEDGEActiveMQ extension allowing per-message acknowledgment. Useful for partial success handling.
## Practical Tips * Use **at-most-once** only when **latency matters more than correctness**. * Use **at-least-once** when **no data loss** is acceptable but you can **handle duplicates**. * Use **exactly-once** when **data correctness and consistency** are critical, and you're willing to accept **lower throughput** and **more complexity**. * For **microservices**, idempotent consumer logic is often preferred to simplify integration with at-least-once delivery. ## **Two-Phase Commit** **2PC** stands for **Two-Phase Commit**, a protocol used in **distributed systems** to ensure **atomicity** (all-or-nothing behavior) across multiple systems or resources (e.g., databases, message brokers like ActiveMQ, etc.) during a **single transaction**. ### What Problem Does 2PC Solve ? Imagine a transaction that: * Sends a message to a queue (ActiveMQ), and * Updates a database record We want either both actions to succeed, or none at all (to prevent inconsistency). However, these systems (ActiveMQ and DB) are separate, possibly on different servers. What happens if one succeeds and the other fails?\ That’s where 2PC comes in. ### How Two-Phase Commit Works ? The protocol has two phases: #### Phase 1: Prepare Phase (Voting Phase) * A Transaction Coordinator asks all involved participants (e.g., DB, message broker) if they are ready to commit. * Each participant: * Writes changes to a temporary log (not visible yet). * Replies with either Yes (ready to commit) or No (rollback needed). #### Phase 2: Commit or Rollback Phase * If all participants vote Yes, the coordinator sends a COMMIT command. * If any participant votes No, the coordinator sends a ROLLBACK to all. * Each participant then either commits or rolls back their part of the transaction. ### Guarantees Provided * **Atomicity**: All operations succeed or none do. * **Consistency**: No system is left in an intermediate state. * **Durability**: If a crash occurs after a commit, the decision can be recovered from logs. ### Trade-Offs
AspectDetails
ProsStrong consistency across services
ConsSlow, can block resources during commit
Failure RiskIf the coordinator crashes in between, participants may be in limbo ("in-doubt" state)
Alternatives3PC (Three-Phase Commit), Sagas, Eventual consistency patterns
### ActiveMQ and 2PC ActiveMQ can **participate in XA (extended architecture) transactions**, which implement 2PC. This allows: * Coordinated commits between **message send/receive** and **database operations** * Configuration via **transaction managers** like Atomikos, Bitronix, or Spring's JTA support **Example Scenario:** * Service receives a request to update customer info and publish an event. * ActiveMQ and our database both register as participants. * The transaction manager uses 2PC to commit both only if both succeed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.pranaypourkar.co.in/the-programmers-guide/spring/spring-features/inter-service-communication/messaging-communication/activemq/message-delivery-guarantee.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.