Overview of Request Concurrency
Learn how Cosmos DB handles conflicts by default and what we can do about it.
We'll cover the following
Request concurrency issues
In Cosmos DB, documents have versions identified with the _etag
property. When different clients update the same document, there can be concurrency issues.
In this lesson, we’ll see how Cosmos DB helps us reduce issues and how we can handle them.
Single-region writes
Let’s see three examples of concurrency issues that might happen.
Imagine Alice and Bob working in the same region, trying to update the same document.
First scenario
Alice and Bob update the same document at the same time. Which one will succeed?
Second scenario
In chronological order:
Alice reads version 1.
Bob reads version 1.
Alice successfully updates the documents, creating version 2.
Bob tries to make an update.
Will Bob override and lose the changes made by Alice?
Third scenario
Similar to the second scenario:
Alice reads version 1.
Bob reads version 1.
Alice deletes the document.
Bob tries to make an update.
Will Bob recreate the document? Will it be version 1 again or version 2?
Multi-region writes
Imagine our data is stored in two regions (Europe and the US). We can write on both; currently, both have version 1 of a document.
Alice updates the document in West Europe, effectively creating version 2 in West Europe.
Bob updates the document in the East US, effectively creating version 2 in the East US.
Both updates are successful, because there are no conflicts in the respective regions. But what happens when regions try to sync their changes?
Conflict handling
We first need to understand the two main layers involved in the operations:
The optimistic concurrency control (OCC) layer
The logical partition database engine
The logical partition hosts the database engine, and each operation is subject to pessimistic locking. The logical partition is locked, and only one operation can run. If two concurrent operations attempt to update the same document, one succeeds and one fails.
However, the OCC should detect the conflict and prevent this from happening.
Optimistic concurrency control
Pessimist locking is terrible for performance; it prevents us from running queries in parallel, even if they don’t need the same documents or they don’t update them. For this reason, OCC is used before reaching the engine. OCC is also called optimistic locking; multiple operations can run without interfering. When it’s time to commit a change, the database checks that another operation is not modifying the data. If a conflict happens, the operation is rejected.
OCC in Cosmos DB
In Cosmos DB, each document has an _etag
property that is updated automatically by the engine with each update.
It looks something like this:
Get hands-on with 1200+ tech skills courses.