What happens when my application consumes an MSMQ message but then fails?

Question

If I ask Bob to get me a sandwich and Bob says "Ok," but then he is hit by a bus on his way back from the shop, I will never get my sandwich--and I don't know I'm not going to get my sandwich!--so I don't tell anyone else, "hey, I'm hungry!"

Is there a way to deal with this problem in MSMQ? Can I reserve a message so that it won't be passed to anyone else but not consume it so that I can put it back in the queue later if I choke on it?

I don't even know what you'd call that. :|

Clarification: I'm using a transactional queue. But if the consumer receives a message (and the message is removed), what happens when that consumer then fails to do what the message is asking it to do? Is the only option to have the consumer put it back on the queue?

Answer 1

This is called “exactly-once semantics” and is quite hard to achieve for any distributed process; it is not specific to MSMQ.

The typical way of handling it is to use a sliding delivery window; tell Bob “Hand me a sandwich before 1PM or forget it”. Then, if you haven't got a sandwich by 1PM, tell Claire “Hand me a sandwich before 2PM or forget it”. If Bob is rushing back with your sandwich and he sees it's after 1PM he has to decide what to do with the sandwich, but he can't give it to you.

There is actually a fair bit of research on this topic; Google “exactly once”. I see Microsoft is claiming MSMQ supports it through MQMgmtGetInfo .

Answer 2

Ok, so I finally found an answer: you can use transactions on the Receive() call just as you can on the Send() call. You can then abort the transaction and it will be rolled back, leaving the message in the queue (provided, of course, that you use a transactional queue).

I actually found this answer on StackOverflow ( MSMQ receive with transaction - rollback not making message available again ), but the question asked there was entirely different, so it wasn't all that easy to locate.

I'm leaving this question up just in case the semantics more closely match someone else's Google search.