Freigeben über

Another New Feature: Transactional Remote Receive

  • Artikel

MSMQ has supported receiving messages from queues hosted on other machines ("remote receive") since the beginning. However, remote receives within a transaction have not been supported. That's a significant detail, and has generated a lot of customer requests, because for many applications transaction support is important. Or, to be more specific, the ability to put a message back into the queue if something fails while processing it is important. If the receive was done in a transaction, then the application can abort the transaction, the message reappears in the queue, and the application can try again later; if the application has failed entirely and the process exits, then the transaction is aborted automatically, and the message is not lost and can be retried when the application is restarted. If the receive was not done in a transaction, then at best the application is left unable to either process it or put it back, and at worse the message simply disappears when the application process exits.

If the application and the queue can be hosted on the same machine, that all works fine. However, in some larger customer scenarios, the actual processing of messages requires a farm of machines running the application to provide sufficient capacity, and the queue is hosted on another machine entirely. The application is now doing remote receives, which cannot be transactional, and that presents the serious application architecture problem I just described. Prior to MSMQ version 4, the best workaround was to make the farm machines MSMQ dependent clients whose supporting server was the machine hosting the queue.

With MSMQ version 4, dependent clients are being phased out for a variety of reasons, so the workaround will no longer be available after a certain point. However, it was a workaround rather than the desirable solution, and the MSMQ team has addressed the impending problem by providing the desirable solution: remote receives using transactions are now available, allowing you to implement your application architecture in the straightforward way. Strictly speaking, this feature isn't quite new, since it has been present since Windows Vista was released a year ago. However, the scenarios it is most useful for are more likely to run on Windows Server 2008, so it will probably attract more attention now.

Note that performing a remote transactional receive requires both the receiver and the queue host to be running MSMQ 4, which means either Windows Vista or Server 2008. It also requires MSDTC (Microsoft Distributed Transactional Coordinator) on both machines so that the transaction can be flowed between them. MSDTC itself is present and running by default, but some additional setup is required to enable it to coordinate cross-machine transactions.

Comments