A transaction is an atomic group of published or accepted messages. It can be viewed as a set of enqueue and dequeue operations on one or more queue. Enqueues occur when messages are published on one or more queues. Dequeues occur when a message is accepted.

The atomicity of the group of operations within a transaction means that they will either all succeed or all fail. In these terms, success indicates that the published messages all become available on their respective queues, and the accepted messages are permanently removed from their respective queues. Failure indicates that the published messages are discarded, the acceptances are ignored and the messages remain unaccepted.

A message published under a transaction will not become available to subscribers on any queue until the transaction is committed. A message that is accepted under a transaction will not be dequeued until the transaction is committed.

If a transaction is rolled-back then all messages published under that transaction will be discarded. All messages accepted under it will remain unaccepted. This means that they will not be returned to the queue or re-delivered unless it has been explicitly requested. The API used will determine the expected behavior. If a transactional session ends without committing a transaction, the transaction itself will be automatically rolled-back.

Both local and distributed transactions are supported by qpidd. In a local transaction the only atomic operations are those that occur on the broker to which the transactional session is connected. Distributed transactions use two-phase commit to achieve atomicity across multiple services.