Transactional MSMQ on a cluster

  • Article

Before Windows 2008 (MSMQ 4.0) there was only one option if you needed to read messages transactionally on a high availability cluster - the application had to be clustered in the same resource group as the MSMQ service hosting the queues. This was because only local receive operations could be transactional on Windows 2003 (MSMQ 3.0).

Now remote receives can be transactional so the application can be run elsewhere, such as on the local nodes, which makes development / testing / administration that much easier.

There is a caveat to this - you will experience a performance difference between local and remote receive operations which makes the decision where to locate applications less clear cut. There are two reasons for this:

  1. Receive operations use RPC. If the application and MSMQ resource are working together, local RPC (LRPC) function calls are made. If the application is remote then the transport protocol has to be used at both ends, adding a large overhead.
  2. For sending messages transactionally over the wire, MSMQ employs its own lightweight mechanism that uses acknowledgement messages. Receiving messages remotely, though, requires DTC for the transactional support which is a much more heavyweight method.

References

[[Thanks to Joseph Donahue for typo checking]]