Default behavior
When simultaneously handling messages, conflicts may occur. See below for examples of the exceptions which are thrown. Saga concurrency explains how these conflicts are handled, and contains guidance for high-load scenarios.
Creating saga data
Example exception:
Raven.Client.Exceptions.ConcurrencyException: Document OrderSagaData/OrderId/316414b3-07f1-40ec-00db-022a4140d517 has change vector A:2-u2LvKAFZTE+972x2hp1gTg, but Put was called with expecting new document. Optimistic concurrency violation, transaction will be aborted.
Updating or deleting saga data
By default, RavenDB persistence uses optimistic concurrency control when updating or deleting saga data, though starting with NServiceBus.RavenDB version 6.5, it's possible to configure the persister to use pessimistic locking. See later in this document for how to do this.
Example exception:
Raven.Client.Exceptions.ConcurrencyException: Document OrderSagaDatas/f23921c9-7b53-455d-89be-aad200d98741 has change vector A:93-u2LvKAFZTE+972x2hp1gTg, but Put was called with change vector A:90-u2LvKAFZTE+972x2hp1gTg. Optimistic concurrency violation, transaction will be aborted.
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.Sagas concurrency control
By default NServiceBus.RavenDB uses optimistic concurrency control. Pessimistic locking can be enabled with the following API:
var sagasConfig = endpointConfiguration.UsePersistence<RavenDBPersistence>()
.Sagas();
sagasConfig.UsePessimisticLocking();
Pessimistic locking internals
RavenDB does not support pessimistic locking natively and the persister uses a dedicated RavenDB document to enforce exclusive saga updates. In some scenarios, this can lead to an increase in I/O roundtrips, especially if many instances are competing for the same saga. However, in high concurrency scenarios, the overhead is still smaller than the cost of message retry that would be caused by optimistic concurrency failures.
Pessimistic concurrency control settings
The pessimistic concurrency control can be customized using the options mentioned below.
Pessimistic lease lock time
By default, the persister locks a saga data document for 60 seconds. Although it is not recommended to have sagas execute long-running logic, in some scenarios it might be required to increase the lease duration. The lease duration can be adjusted using the following API:
var sagasConfig = endpointConfiguration.UsePersistence<RavenDBPersistence>()
.Sagas();
sagasConfig.SetPessimisticLeaseLockTime(TimeSpan.FromMinutes(2));
Pessimistic lease lock acquisition timeout
By default, the persister waits 60 seconds to acquire the lock. The value can be adjusted using the following API:
var sagasConfig = endpointConfiguration.UsePersistence<RavenDBPersistence>()
.Sagas();
sagasConfig.SetPessimisticLeaseLockAcquisitionTimeout(TimeSpan.FromSeconds(15));
Pessimistic lease lock acquisition maximum refresh delay
To prevent request synchronization, the persister randomizes the interval between lock acquisition requests. By default, the interval has a value between 0 and 20 milliseconds. The 20ms default upper limit can be changed to any value between 0 and 1000 milliseconds using the following API:
var sagasConfig = endpointConfiguration.UsePersistence<RavenDBPersistence>()
.Sagas();
sagasConfig.SetPessimisticLeaseLockAcquisitionMaximumRefreshDelay(TimeSpan.FromMilliseconds(500));