Consider enabling the outbox by default?

[danielmarbach]

"The outbox has to be enabled explicitly on the endpoint configuration", seeing as it is "the recommended, safe-by-default configuration".

We could consider in the future to enable the outbox by default when EnableTransactionalSession is called.

Here is some "rough" background information around the original tradeoffs

One of the key design decision of the transactional session was to follow the NServiceBus current outbox design and all that comes with it. As such, the current outbox design is opt-in and has to be enabled explicitly. The transactional session follows that

• So in essence the same argument you are making can be had for the current outbox design. If that is the safe by default choice why isn't it enabled by default on an endpoint?
• The reasons are multifold and partially also legacy. The outbox even was at one point double opt-in! But in essence if I recall correctly parts why the outbox is opt-in is that
• Requiring a persistence for an endpoint is not mandatory
• Having a persistence doesn't mean you are required to have enabled all the nops for the sub storages a persistence supports
• Saga storage and outbox storage, although they work hand in hand have been designed to work in an "escalating" manner meaning that you can run with just saga storage without the outbox
• It is also possible to run with just the outbox storage and not using sagas
• Plus it is possible to just run with what we internally call synchronized storage (basically just letting NServiceBus control the unit of work) without having the outbox enabled or with having the outbox enabled
• With the outbox API extensions not being on the persister, but a dedicated thing there might be persistence specific outbox settings that we want to "surface" into the transactional session behavior. By enabling the outbox internally those settings would have to be "mirrored" to the EnableTransactionalSession API or still be exposed on EnableOutbox which than means the customers end up call EnableOutbox anyway.

Some of these principles have been introduced after the original designs have already been around, and we have not gone back to rediscussing these choices. The transactional session design has not changed that, and as such follows the original design choices.

[SzymonPobiega]

If the transactional session is merged with the core NServiceBus we will have opportunity to redesign the consistency APIs around the user perception, not around technical details such as TransportTransactionMode. I guess we would end up having just three modes visible to the users:

• receive-only/you are on your own/all bets are off
• outbox and transactional session (the default mode, requires configuring persistence, works with all transports)
• transaction sharing (supported only by SQL Server transport and MSMQ+DTC, legacy)

Then we would design a tool that allows moving a system from the transaction sharing mode to the default mode, one endpoint at the time as the transaction sharing mode has significant downsides:

• MSMQ is not a great tool for cloud deployments and is Windows-only
• SQL Server transport performance is significantly lower than a combination of a dedicated messaging platform (such as RabbitMQ) with the Outbox pattern.