You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"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.
The text was updated successfully, but these errors were encountered:
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.
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
EnableTransactionalSession
API or still be exposed onEnableOutbox
which than means the customers end up callEnableOutbox
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.
The text was updated successfully, but these errors were encountered: