Open mauroservienti opened 5 years ago
@mauroservienti Since we say, even for the legacy system there is a way to work around this (that is, by having the database tables in the same database), isn't this an even smaller edge case?
So in effect, this would be an issue only if they don't want to mix the outbox tables with the application tables?
I'm wondering if that is the case, this is a big enough issue to get prioritized?
I tend to agree @HEskandari. Would be interesting to know from @DavidBoike and @SzymonPobiega what could be the effort to get this in SqlP and NHibernate. Because if the effort is very low it might solve a blocking problem for some customer.
@mauroservienti it should not be a huge thing. Question is, why do we need to change it in both? How about we change these persisters so that you can mix/match outbox and sagas i.e. use SQLP outbox and NH sagas. Then we only change the SQLP outbox to support TransactionScope
. The added benefit is that we can basically say to our customers: always go for the SQLP as a default option. Then if you need your saga data to be stored in proper relational form, add NH persister to the mix.
Then gradually we would be able to reduce the NH persister so that it supports only the sagas.
We absolutely don’t need to change both. That’s a very good point. If we can enhance SqlP and solve the problem for NH users as well that’s even better.
❤️ . SQLP outbox/timeouts + NH sagas is my dream
Quoting @mauroservienti
In the scenario that @mauroservienti described the only way to introduce effectively-once messaging is through an outbox table that is deployed in a separate DB that can participate in a distributed transaction alongside the legacy DB.
The caveat here is that we really don't want our greenfield customers to go that route because we believe it leads to fragile design.
Relevant information
Completed in NHibernate: https://github.com/Particular/NServiceBus.NHibernate/issues/274