Skip to content
Mogens Heller Grabe edited this page Nov 7, 2013 · 14 revisions

Distributed transactions?

Out of the box, Rebus will NOT use DTC. This is a deliberate design choice, because my opinion is that data consistency and resiliency against failures are are much better handled by being conscious about how those things work and what the consequences are.

Another thing is that distributed transactions are usually quite expensive, performance-wise, because of the communication overhead involved. Also, since DTC (as everyone else) is subject to the CAP theorem, it will have to give up availability (the 'A' in CAP) when a network partition occurs.

So, how does it work then?

To put it shortly: By committing transactions in the right order.

I want to use DTC!

If you want to use DTC, you'll have to do some work yourself. At the moment, no transport implementation exists for Rebus that can enlist in a distributed transaction.

It shouldn't be that hard to create one though, e.g. by grabbing the existing MsmqMessageQueue, copy the source code to a new class, e.g. DtcMsmqMessageQueue, and then use MSMQ in a way that enlists the queue transaction in a way that allows for DTC escalation.

Clone this wiki locally