Case 1: Multiple concurrent cluster transactions
Optimistic concurrency for cluster-wide transactions is handled using the compare-exchange feature.
The transaction compare-exchange operations are validated and if they can't be executed because the compare-exchange values
have changed since the transaction was initiated, the entire session transaction is aborted and an error is returned to the client.
Optimistic concurrency at the document level is not supported for cluster-wide transactions.
Compare-exchange operations should be used to ensure consistency in that regard. Concurrent cluster-wide transactions are guaranteed
to appear as if they are run one at a time.
Cluster-wide transactions may only contain
DELETE commands. This is required to ensure that we can apply the transaction
to each of the database nodes without regard to the current node state.
If the concurrency check of the compare exchange has passed, the transaction will proceed and will be committed on all the database nodes.
Case 2: Concurrent cluster and non-cluster transaction
When mixing cluster-wide transactions and single-node transactions, you need to be aware of the rules RavenDB uses to
resolve conflicts between them.
Documents changed by the cluster wide transactions will always have precedence in such a conflict and will overwrite changes
made in a single node transaction. It is common to use cluster-wide transactions for certain high-value operations such as
the creation of a new user, sale of a product with a limited inventory, etc., and use single-node transactions for the common case.
A single node transaction that operates on data that has been modified by a cluster-wide transaction will operate as usual, as the cluster-wide
transaction has already been applied (either directly on the node or via replication)
the cluster-wide transaction will not be executed again.
Replication will try to synchronize the data, so in order to avoid conflicts
every document that was modified under the cluster transaction will receive the special
Change Vector and the special flag
FromClusterTx which ensures precedence
over a regular change vector.
Case 3: Cluster transaction with an External incoming replication
While the internal replication with the cluster is discussed in the previous case, the case where two clusters are connected via
external replication is a bit different.
The logic of documents that were changed by a cluster transaction versus documents that were changed by a regular transaction stays the same.
However, in the case where a conflict is on a document that was changed by both a local cluster transaction and a remote cluster transaction,
the local one will have precedence. Furthermore, the
FromClusterTx flag will be removed, which means that on the next conflict the local
is no longer treated as modified by a cluster-wide transaction.