Default behavior
When simultaneously handling messages, conflicts may occur. See below for examples. Saga concurrency explains how these conflicts are handled, and contains guidance for high-load scenarios.
Starting a saga
Example exception:
System.Exception: Failed to ExecuteNonQuery. CommandText:
insert into [dbo].[Samples_SimpleSaga_OrderSaga]
(
Id,
Metadata,
Data,
PersistenceVersion,
SagaTypeVersion,
Concurrency,
Correlation_OrderId
)
values
(
@Id,
@Metadata,
@Data,
@PersistenceVersion,
@SagaTypeVersion,
1,
@CorrelationId
) ---> System.Data.SqlClient.SqlException: Cannot insert duplicate key row in object 'dbo.Samples_SimpleSaga_OrderSaga' with unique index 'Index_Correlation_OrderId'. The duplicate key value is (7402c6a7-00bc-40a4-bde2-6e32ec13a7c2).
Updating or deleting saga data
Starting in version 4.1.1 conflicts cannot occur because the persistence uses pessimistic locking. Pessimistic locking is achieved by performing a SELECT . or its dialect-specific equivalent.
Up to and including version 4.1, SQL persistence uses optimistic concurrency control when updating or deleting saga data.
Example exception:
System.Exception: Optimistic concurrency violation when trying to complete saga OrderSaga 699d0b1a-e2bf-49fd-8f26-aadf01009eaf. Expected version 4.
This means that the relevant Handle method 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.