Transaction Programming Considerations

The following issues are unique to MSMQ transactions:

There are five ways to send and receive transactional messages: MTS transactions, MS DTC external transactions, MSMQ internal transactions, XA-compliant Transactions, and single-message transactions.
When sending messages, the application must get a successful return code from the call to MQSendMessage and a successful return code from its commit call before it can be assured that the message will be sent.
If some operations in a transaction fail, it is the application's responsibility to decide whether to terminate the entire transaction (by calling the transaction object's abort member function) or commit the transaction anyway (if the failures are such that the transaction is still viable). If the application does commit to a transaction where some operations have failed, the failed operations will not be part of the transaction.
There is no limit to the number of messages sent, the number of messages retrieved, or the number of queues used in a single transaction. However, an application cannot send a message to a queue and then try to retrieve it during the same transaction.
Messages can be sent to a local or remote transaction queue, but messages can only be received from a local transaction queue.
Calling MQSendMessage does not actually send the message within the transaction. The actual sending is done at some time after MS DTC commits the transaction. When MS DTC returns a successful commit return value, the sending application is guaranteed that the message will be sent. If a transaction is aborted, all MSMQ transaction operations are rolled back: no messages are sent, and all retrieved messages are returned to their original place in the queue.
MSMQ guarantees exactly-once-delivery. This means that all messages sent to a queue will arrive once and only once. MSMQ takes special measures to prevent any message duplication or loss.
MSMQ guarantees that all messages sent to a specific transaction queue will arrive in the order they were sent by the transaction. This means that if transaction T1 sends messages M1 and M2 to queue Q1, M1 will arrive before M2.
However, there is no guarantee if two transactions are sending messages to the same queue. If transaction T1 sends messages M1 and M2 to Q1, and a second transaction T2 sends messages M3 and M4 to Q1, MSMQ only guarantees that M1 will arrive before M2, and that M3 will arrive before M4. In order to guarantee that M1 and M2 will arrive before M3 and M4, the application must commit to T2 only after getting a successful return code from T1.

MSMQ does not guarantee order of delivery to different queues, nor does it guarantee order of delivery from different computers.
One may receive messages from a transaction queue using non-transactional receive operations.