[rabbitmq-discuss] Consuming a Rollbacked Message
tonyg at lshift.net
Sun Apr 26 13:07:33 BST 2009
Amin Abbaspour wrote:
> What I can? Is there something wrong with my rollback or ACK
> mechanism? should I do something more than a simple txRollback()?
TX-class transactions introduce grouping and limited atomicity for
*publishes* and *acknowledgements*. This means that the scope of a
transaction is only those basic.publish and basic.ack operations that
the client has performed within the transaction. In particular,
basic.delivers are not included in a transaction -- so it would be wrong
for the server to resend them on a rollback!
A rollback, then, does not release any messages to other consumers, or
cause them to be redelivered to this one; it is assumed by the server
that since the client has seen the messages, and has clearly not crashed
(since the connection is still open and healthy), there is no need to
resend them. The server can trust the client in this case to continue
thinking about which messages to acknowledge, and will wait for
subsequent basic.acks followed by tx.commit.
If the client has forgotten what it has seen, it can use the
basic.recover operation to get its pending deliveries resent.
Alternatively, it can close and reopen the channel (though this has
This is a confusing area of the spec: not only did we initially get our
implementation wrong, other implementations did too, and in fact the 0-8
spec does not fully specify the behaviour of rollbacks or basic.recover
operations. Furthermore, there is a legitimate, if subtle, design
question here: seen one way, the current behaviour -- transactional acks
-- is correct; seen another, the alternative -- transactional deliveries
-- is correct. (If you're interested, the former seems natural in a
hub-and-spoke design for AMQP, but the latter starts to look oddly
sensible in a fully peer-to-peer, internet-scale design...)
More information about the rabbitmq-discuss