To understand clearly reliability features of the BizTalk RFID stack I decided to describe shortly transaction support of the MSMQ. If you are not a BizTalk or RFID developers, this could be anyhow useful to understand MSMQ transactions at all. In general I would recommend to read this article if you are not familiar with MSMQ programming at all.Additionally this article describes MSMQ in context of reliability more precisely.
If you want to post the message in the queue following snippet can be used. Note that th emessage in example below is serialized for BizTalk RFID stack. More about BTS RFID message serialization and queuing can be found here.
Note that the line mq.DefaultPropertiesToSend.Rcoverable = true forces the queue to persist all messages on the disk. This ensures reliability feature.
Now, assume we want to read this message by using of transactions. First, it is important to know that the MSQM supports two kinds of transactions: Internal and External. Internal transaction is transactional reading and writing of messages from and to MSMQ. This one is fast, but it does not involve DTC. Example above shows hot to use internal transaction to send the message in the queue.
Next example shows how to make a usage of internal transaction by receiving of the message:
After the transaction MessageQueueTransaction (the internal one) has been started (mqt.Begin()) the message is read from the queue. If you take a look in the queue the message is no more there. If the exception is thrown or mqt.Abort() invoked, the transaction is rolled-back and the message is written back to the queue. In opposite, invoking of mqt.Commit() commits transaction and the message is no more in the queue.
Next example shows how to make a usage of DTC (external transactions).
Here we start the TX context before the message is read from the queue. By reading of the message
Message msg1 = mq.Receive(MessageQueueTransactionType.Automatic);
By reading, the message is received by using of externally started transaction. If the transaction is rolled-back, means the message is posted back in the queue. To do that either rollback can be invoked or an exception can be thrown.
To complete the transaction call scope.Complete(). In this case the message is removed from the queue, because it has been successfully read.
Last example shows a peace of code which implements reading of the message out of transaction scope. This has a result, that the receiving of the message does not participate in the transaction. That means, after the message is read, it will not be posted back to the queue if the transaction is rolled back or an exception has occurred.
May 12 2008, 06:09 PM