AMQP transactions
An AMQP 1.0 transaction is declared at the broker's coordinator, and the transfers posted under it reach their nodes together on the commit or not at all.
The diagram as text
- declare on the controller link → declared the coordinator's txn-id: coordinator
- declared the coordinator's txn-id → transfers on sender links carry the txn-id: txn-id
- transfers on sender links carry the txn-id → discharge fail=false commit
- discharge fail=false commit → accepted: the messages reach their nodes together: accepted
- transfers on sender links carry the txn-id → discharge fail=true: rollback, nothing is delivered: or
- Before the discharge, no consumer sees a message posted under the transaction
The coordinator is a node of the broker. A controller link attaches to it and sends declare, and
the coordinator answers with a transaction id. A transfer on any ordinary sender link then carries
that id in its transactional state. discharge ends the transaction: with fail false it commits,
and with fail true it rolls back.
AmqpTxnPublisher posts under a transaction. Each
begin_transaction attaches a controller link on the connection's publisher session and declares
one transaction, and commit and abort discharge it. The controller asks for the mixed
sender settle mode, because Artemis answers with that mode and the client requires the broker to
echo the one it asked for.
Brokers differ here. Artemis serves one transaction per session, and the publishers of a connection share one session. RabbitMQ 4 does not support AMQP 1.0 transactions. Azure Service Bus supports them, and posts to several entities in one transaction through a send-via entity.
The protocol is the specification's (transactions), and the broker limits are each vendor's (Artemis, RabbitMQ, Service Bus).