SQL Transactions involving OpenSleigh and my Business code

[nicogiard]

Hi David, another question for you :x

I tried to add some features in the Sample4 (rabbitMQ + MSSQLServer) to achieve a "real life" test.

If i'm correct, a SQL Transaction is created by the SagaRunner just before the call to "HandleAsync" of a SagaState, and is commited if everithing is ok.

How can i introduce, in the HandleAsync method, some business code?

For example, i would like to persist an object "ShippingOrder" in the "ShippingService" during the ShippingSagaState.

Should i extends / override the SagaDbContext ?
Can i add a completely different "ShippingDbContext" of mine ?
How does the transaction beetween those two contexts will opear ?

If my explanation lak of details, i can try to make a branch in my fork to show what i want to achieve.

Thanks a lot for all the time and efforts.

[mizrael]

hi Nicolas! You should not modify or use SagaDbContext outside the OpenSleigh scope, but instead create another one, specific to your application. The transactions are independent one from the other, OpenSleigh doesn't really care what you do inside the handlers, it only monitors the exceptions (if any).

I would be happy to review some code if you want, that might also help creating a better sample :)

[nicogiard]

When you read the "Transactional Outbox Pattern" presentation (https://microservices.io/patterns/data/transactional-outbox.html), it says that both insert (business and outbox) should be made in the same sql transaction.

Don't you thing your implements can potentienly have flaws if a problem occurs just after the commit on the business code but juste before the "outbox" commit ?

Wouldn't the use of a TransactionScope allow to do everything in a common request?
Or if we pass the Transaction instance to the HandleAsync method to perform a "context.Database.UseTransaction(transaction);" ?

[mizrael]

I'm not sure I agree with that statement. OpenSleigh has its own "business" context, and the Outbox implementation is internal and scoped to the library's needs. Moreover, the enclosing application might use a different persistence layer for its data (although unlikely).

In theory, nothing should occur after the commit on the business code, apart from the Outbox processing, which is guaranteed to happen at least once. Business code should be wrapped into its own transaction with its own rules. Any exception will be captured by OpenSleigh, will prevent the State from being persisted and the Outbox from being processed.