Closed AfanasievAndrew closed 6 months ago
Rebus uses optimistic concurrency control around saga updates, so the two messages will seemingly be processed in parallel, but only the first one's update will go through ā the other one will get an ConcurrencyException
and be rolled back and retried, this time executing on an up-to-date saga data. š
I've taken your code to demonstrate the principle here: TestSagaOptimisticConcurrency
Please let me know if it isn't clear how it works from the example.
If you run two hosts in parallel and send two messages for processing for one saga, then the saga data can be overwritten, judging by the behavior, the saga data is read at the time of entering the handler and there is no lock when changing.
My example:
Saga storage SqlServer (StoreInSqlServer) and transport RabbitMq (UseRabbitMq).
Sending messages:
And the logs of the hosts:
Rebus 8.0.2 Rebus.RebbitMq 9.0.1 Rebus.SqlServer 8.0.2
It looks like the second host should be set to 'true' at the time of reading the saga data, or in that case there should be sequential message processing.