NServiceBus and DTC's

Question

Im using the Distributor in NServiceBus and i've hit a wall of ignorence regarding DTC's. Ive only used DTC once maybe twice before when doing stuff across processes and not a lot, so im very newbie with the whole DTC concept.

Question:
To ensure durable messaging with NSB, is it absolutely necessary to use DTC's?

The reason I ask is that i would expect NSB be able to detect any exception in, say a handler, and therefore react to the error by not removing the message from the queue. Hence no need for DTC. That would of course mean that any database or external service access in the handler would require the programmer to perform hers/his own rollbacks etc. And for that reason DTC's does seem like the best way to go. So Im all for DTC's (if I understand them right) as they from my perspective ensures that messages never are lost from the queues and message handling will never be corrupt as long a the handlers are implemented correctly and have other external services participate in the DTC.

But im not sure, especially since a well respected guy in the server maintenance team used the sentence "DTC's will cause you a world of pain!" when I ran the idea of activating DTC's on the database server by him... But he have yet to come with argument as to why im in for so much pain with DTC's... :/.

Could someone with a good understanding of DTC's and NSB please help me clearify whether im completely off in my understanding of DTC's and whether there's some big pitfall I have completely missed with DTC's?

Kind regards

Answer 1

NServiceBus distributor and the use of DTC in NServiceBus don't have anything to do with one another. DTC will be used by NServiceBus whether you're using the distributor or not.

NSB distributor workers (and even the individual worker threads on a single box when the NSB distributor isn't used) don't enlist one another in distributed transactions. Let me reiterate, you will never see two NSB worker threads in a single DTC transaction. Each worker thread starts a transaction against a local queue and then adds a (likely remote) database to the transaction (which makes it distributed)

There's a nice illustration of the concept here

I don't think you're missing any big pitfalls. I'd just decouple the two concepts, NSB distributor and how distributed transactions are used by NSB