How to do Document-level locking on MongoDB and .NET Core
Published: 2021-01-11 22:04:00

Hi All! Today we're going to see how MongoDB handles locks and how we can achieve Document-level locking.

The default MongoDB storage engine, *[WiredTiger](https://docs.mongodb.com/manual/core/wiredtiger/),* uses optimistic concurrency control, or OCC. In a nutshell, it assumes that

> multiple transactions can frequently complete without interfering with each other.
>
> *[WIKIPEDIA](https://en.wikipedia.org/wiki/Optimistic_concurrency_control#:~:text=Optimistic%20concurrency%20control%20(OCC)%20is,without%20interfering%20with%20each%20other.)*

This basically means we're somewhat sure that nobody else is going to update our data while we're working on it.

#### In case that happens, one operation is going to succeed, while the others will fail, entering some kind of retry loop.

We're relying on the nature of the data and the operations available on the Domain. In short, we're being *optimistic* that things will end up just fine.

When we want to be absolutely sure that only one consumer will be able to operate a specific set of data, we could use some form of locking.

This falls into the realm of *Pessimistic Locking*: we block access to the data till we're done with it. The drawback is simple: what if we never release a lock? The other consumers will deadlock, so we need a proper strategy (for example timeouts) to handle those cases.

It can get complicated and ugly pretty quickly so be careful.

There might be some situations, however, where you need more fine control over the locking strategy, for example when you're dealing with [Sagas and Distributed Transactions](https://www.davideguida.com/opensleigh-a-saga-management-library-for-net-core/?swcfpc=1).

Now, WiredTiger [allows locking](https://docs.mongodb.com/manual/faq/concurrency/) only at the global, database or collection levels. This means that we cannot lock a single document.

Luckily for us, operations on MongoDB are atomic, so we can "fake" some sort of pessimistic locking and handle part of the complexity on the application side.

The idea is to decorate every document with two additional properties, something like:

```
{
    "LockId" : UUID("6ca9d76f-01ac-42cc-88ca-b2ecd5b286c3"),
    "LockTime" : ISODate("2020-12-28T04:42:13.528Z")
}
```

When we want to lock a document, we fetch it by ID but we also make sure that *LockId* is null. Additionally, we can also check that *LockTime* is after a specific window: this way we can discard previous locks if they're expired.

#### Using the [*FindOneAndUpdateAsync* ](https://api.mongodb.com/csharp/current/html/M_MongoDB_Driver_IMongoCollection_1_FindOneAndUpdateAsync__1.htm)API, we can fetch the document and in the same operation, we can set both *LockId* and *LockTime*.

We'll also configure the call to be an *upsert*: this way if the document is not in the DB yet, we can also create it. Moreover, the next time someone is trying to access it, the engine will throw a *MongoCommandException* instead.

When we're done with the document, we can release it by simply setting to null both *LockId* and *LockTime*.

Just for you to know, a while ago I started working on [OpenSleigh](https://github.com/mizrael/OpenSleigh), a distributed saga management library for .NET Core. It uses the same technique in its MongoDB [persistence driver](https://github.com/mizrael/OpenSleigh/blob/develop/src/OpenSleigh.Persistence.Mongo/MongoSagaStateRepository.cs).

The [next time](https://www.davideguida.com/how-to-do-document-level-locking-on-mongodb-and-net-core-part-2/?swcfpc=1) we'll see a small demo and dig a bit more into the details. Stay tuned!