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 1400+ tech skills courses.