SQL persistence honors concurrency semantics in the following ways.
The persister uses unique key constraints that will result in an exception being thrown if two saga instances with the same correlation value are created at the same time.
To ensure correctness, when creating new sagas, the persister applies optimistic concurrency using an incrementing counter. The persister uses an explicit version column combined with the
ReadComitted isolation level.
However, to avoid excessive conflicts for highly congested sagas, the persister uses pessimistic concurrency for querying and updating saga information. The pessimistic concurrency is implemented using a
SELECT . construct or its dialect-specific equivalent.
Handlemethod on the saga will be invoked, even though the message might be later rolled back. Hence it is important to ensure not to perform any work in saga handlers that can't roll back together with the message. This also means that should there be high levels of concurrency there will be N-1 rollbacks where N is the number of concurrent messages. This can cause throughput issues and might require design changes.