I’m just starting to mess around with NServiceBus sagas. However the docs does not seem to say anything about wether or not the invidual handle methods on a saga instance can be executed in parallel or not?
If they can executed in parallel, is there some way it can be turned off, at least for a given instance of a saga?
The method of maintaining consistency with respect to concurrent message processing depends on the persister being used. Some may use a transactional lock, and others may perform an atomic change with optimistic concurrency control.
If Saga (type) handles multiple message types and those messages arrive at the same time, based on the concurrency, the saga will be invoked multiple times, but only one message will be the “winner” and the rest will be rolled back and retried.
If they can executed in parallel, is there some way it can be turned off, at least for a given instance of a saga?
Not for an instance of a saga, but could be for a specific saga type, if it’s isolated to its own endpoint with concurrency set to one.
That seems to be good/safe enough for what we are going.
Specifically we are adding items to a list in the saga data.
I do then assume that I should be very careful about touching my database. If I need to touch the database, is it then better to emit new commands to self to update state? (a progress measure in this case)
You don’t need to assume. It’s described in the documentation.
Other than interacting with its own internal state, a saga should not access a database, call out to web services, or access other resources - neither directly nor indirectly by having such dependencies injected into it.
Correct. Actual work should not be done by the saga itself, but rather by external to saga handlers.
Ahh, thank you, I must have missed that entire page when looking through the documentation. My bad.
No worries. The page is packed with the information that can help when working with Sagas. Good luck.