CODEWITHSUNDEEP
nservicebusmasstransit
Pavel Voronin
Pavel Voronin

Reputation: 13983

What's the value of concurrency for sagas?

I do not get the purpose of concurrent messages for saga. I'd expect it to behave more like an actor. So all the messages with the same CorrelationId are processed sequentially. The whole purpose of saga is orchestration of a long running process, so why does parallel message processing matter?

Can you give a legit example where handling messages concurrently for the saga instance is beneficial compared to the sequential mode?

Or do I understand it wrong, and concurrency just means several different saga instances running in parallel?

The reason to ask is this fragment from NServiceBus docs:

The main reason for avoiding accessing data from external resources is possible contention and inconsistency of saga state. Depending on persister, the saga state is retrieved and persisted with either pessimistic or optimistic locking. If the transaction takes too long, it's possible another message will come in that correlates to the same saga instance. It might be processed on a different (concurrent) thread (or perhaps a scaled out endpoint) and it will either fail immediately (pessimistic locking) or while trying to persist the state (optimistic locking). In both cases the message will be retried.

Upvotes: 2

Views: 1246

Answers (1)

Alexey Zimarev
Alexey Zimarev

Reputation: 19610

There's none, messages for the single saga instance need to be processed sequentially. There's nothing special about saga configuration in MassTransit, you really want to use a separate endpoint for it and set the concurrency limit to one.

But that would kill the performance for processing messages for different saga instances. To solve this, keep the concurrently limit higher than one and use the partitioning filter by correlation id. Unfortunately, the partitioning filter requires by-message configuration, so you'd need to configure the partitioning for all messages that the saga consumes.

But it all depends on the use-case. All the concurrency issues are resolved by retries when using the persistence-based optimistic concurrency, which is documented per saga persistence provider. Certainly, it produces some noise by retrying database operations, but if the number of retries is under control, you can just keep it as it is.

If you hit tons of retries due to massive concurrent updates, you can revert to partitioning your saga.

Upvotes: 4

Related Questions