how to configure nservicebus using gateway when MSDTC not available either end

0
votes

I am new to NServiceBus, trying to introduce messaging into a WCF/RPC solution.

Because of architectural constraints and overhead (memory and cpu usage already high) IT Operations will not allow MSDTC. (I'm also keen to avoid 2PC fwiw). I also require messages over http so the NSB bridge looks like a great solution.

Based on these posts (how-i-avoid-two-phase-commit and extending-nservicebus-avoiding-two-phase-commits) it looks to me as though it's possible to use NSB with the DTC disabled. It sounds like EventStore does manage to avoid 2PC in the same way that I want to setup NSB but at the moment I just want to get NSB to work rather than adding event sourcing into the mix.

Questions:

  1. Are there any examples of configuring NSB to work this way? I'm quite happy to add the extra complexity (custom message handler with local message state storage) - without 2PC there isn't really another option. I already know of this example (IdempotentConsumer) but the test projects for this repo contain no code. It would be even more helpful if there was an example using nosql storage.
  2. Will I need to alter the NSB bridge to deal with no DTC? I'm guessing no - bridge transactions are only against the local queue but the process that consumes the local queue will obviously need to coded to avoid 2PC. Correct?
  3. Are there any other useful resources/posts around using NSB without MSDTC? The solution (how-i-avoid-two-phase-commit) seems not too complex but given I'm just starting out with NSB it would be great to find a quickstart for this...
  4. I would have thought this would be a common scenario - but there doesn't seem to be much written about avoiding MSDTC while still using NSB. Surely there are others who are using a message bus but aren't allowed to use MSDTC... Is there another obvious way that I've missed?

thanks

1
nservicebuscqrsevent-sourcing
Rant ahead: "memory and cpu usage already high IT Operations will not allow MSDTC". Its always funny how IT ops and DBA's can make decisions that can have fundamental effects on how the software is built and ultimately the cost. Not saying that ES and all that is bad, quite the opposite but it should be used because the business needs it and not because some guy at IT ops thinks memory is expensive. Trust me dev hours is way more expensive that memory and cpu. - end rant – Andreas Öhlund
yes, I'm well aware that dev time is more expensive than hardware. I don't think moving away from MSDTC is all bad - it's a bit restrictive as to which persistence stores we can work with. That's why I'm surprised that there doesn't seem to have been more talk around NSB (forums, etc) about removing the hard requirement for MSDTC (which I guess could only be done by including in the NSB install a solution like jonathan oliver describes). Regardless, no MSDTC is the constraint I've been dealt - so I'd really love to see an example of how to work around it. – Justin
I wouldn't call it a "hard" requirement of nsb. You can turn it off by calling configure.IsTransactional(false). There isn't much we can do to help further since you essentially needs code you're way out of it. But ES of course makes that alot easier. – Andreas Öhlund

1 Answers

1
votes

2) Yes you should be fine. Since you're doing the deduplication your self you don't need the gateway to do it for you. Just configure it to use the InMemory persistence and you should be fine.