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, uses optimistic concurrency control, or OCC. In a nutshell, it assumes that

multiple transactions can frequently complete without interfering with each other.

wikipedia

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.

Now, WiredTiger allows locking 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 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, a distributed saga management library for .NET Core. It uses the same technique in its MongoDB persistence driver.

The next time we’ll see a small demo and dig a bit more into the details. Stay tuned!

Did you like this post? Then