[rabbitmq-discuss] Consuming a Rollbacked Message

[Tony Garnock-Jones]

Hi Amin,

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 
other consequences).

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...)

Regards,
   Tony