RavenDB honors concurrency semantics in the following way.
RavenDB lacks support for unique indexes, so the persister mimics this by creating a separate document for each saga to serve this purpose. The key of this document is set to the value of the correlation property, this causes RavenDB to throw a exception should two documents with the same correlation value be created at the same time.
The persister makes use of RavenDB optimistic locking causing concurrency exceptions to be throw should the same saga instance be updated concurrently.
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.