"mark.little(a)jboss.com" wrote : "timfox" wrote : Another common situation is that users find using XA too slow to bridge each message from one provider to another, so instead opt for "DUPS_OK" quality of service mode, and then just detect duplicates in their own code at the end. | | You know XA (and transactions in general) are much more than this, right ;-)?! I'm describing a very common pattern where users want an end to end "once and only once" delivery guarantee, but don't want to use XA to accomplish this because of performance issues. E.g. you have a set of queues potentially each one living on a different system. Messages are consumed from one queue, the message is processed then the same or another message is passed to another queue for the next stage of the workflow. If the system crashes at any point we don't ever want to be in a situation where the workflow stops mid way through, i.e. lose messages. The "obvious" way to do this is after processing the message, to acknowledge it from the current queue and send it on to the next queue in a single transaction. If the two queues are on different resource managers this would involve XA. Alternatively you can send the message on to the next queue and acknowledge it from the current queue in separate transactions, but make sure that you send it on *before* you ack it. In case of failure you may end up with the message sent, but not acked. So on recovery the same message might get processed again (i.e. you have duplicates), but you'll never end up losing a message. Then, at the application level, you implement your own duplicate detection. E.g. you discard any messages whose id you have seen before. You can keep a cache of ids of the message you have seen. This of course needs to be persisted. So the end result is a "once and only once" guarantee but without XA. (Assuming an infinite cache - but it's a trade off) Anyway, don't know why you asked the question Mark, you know all this already :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139405#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...