We’re looking into migrating our NServiceBus endpoints to Azure. We have 20+ endpoints all using the following configuration: SQL transport + NHibernate persistence + MSDTC. All endpoints use a single database for queues, subscriptions and timeouts. Each endpoint has its own database with business data.
We’re working on a migration strategy moving away from MSDTC. Our handler implementations are not idempotent. So besides re-implementing all handlers, we see these two options to mimic the DTC behavior:
Use the outbox
Use the synchronised session storage to reuse the NServiceBus SQL connection/transactions
Questions
How is the same connection/transaction reused for both outbox and business data? Does this only work when business data is accessed using the SynchronizedStorageSession?
If so, what’s the benefit of using the outbox when using the SQL transport and persistence and accessing business data using the SynchronizedStorageSession? Then they all share the same connection/transaction?
When using the outbox, is it possible to keep subscriptions/timeouts in a shared database but store the outbox data in the ‘business’ database?
Synchronized storage session is indeed the way to make sure the same SQL connection is used for both outbox and business data so that both are sharing the same database transaction.
Correct
Subscriptions are idempotent and to not require outbox. You could store these separately.
Timeouts are handled by the transport, you should use native delayed delivery:
So there’s no benefit of enabling the outbox other than easy switching to another transport later on?
At the moment we still use the timeout manager, not SQL native delayed delivery. The ‘old’ timeout manager has no exactly-once delivery when pulling messages out of the timeout storage and putting them on the transport. Is this also fixed when moving to native delayed delivery?
I want to know if there’s any the benefit of enabling the outbox in a scenario where you use SQL Server for transport, persistence and business data? Consistency is guaranteed by using a single SQL connection and transaction.
If I understand correctly, the outbox can ensure the same consistency level and it allows you to use a different technology for transport and persistence/business data. But, its not free. It add extra complexity and requires tracking which messages were already processed.
So, is it correct that there’s no benefit of enabling the outbox is this scenario?
That is correct, if you use SQL Transport and SQL Persistence and both share the same database then it can work without outbox and still be consistent. We have a sample that shows this:
If your system deals with non-transactional integrations then these could result in more-than-once processing of incoming integrations channels. The outbox would guarantee transactional exact-once on such channels if the message identifier is used for deduplication.