JIYIK CN >

In database management systems, locking mechanisms ensure the consistency of the entire result.

For example, if some writing process is in progress on the data, a read command cannot be executed at the same time. Database resources are locked to prevent inaccurate data caused by such situations.

MongoDB also uses locking to ensure data consistency because multiple clients can access or modify the same data at the same time. In this article, we will explain the concept of locking in MongoDB.

Locking in MongoDB

Locking in MongoDB is different from locking in other relational database management systems. Let us describe to you how locking works in MongoDB.

MongoDB uses multi-granularity locking. This means that processes can be locked globally, at the database or collection level, or even at the document level for a single storage engine.

These levels of locking are described further in this article. In recent versions of MongoDB, starting with v2.2, each database has a reader-writer latch.

Because of these reader/writer latches, concurrent access to database resources is possible. Let's explain how these work.

Reader/Writer Latch

MongoDB's read/write latches can be best explained as having the following properties:

1. It is a multi-reader. This means that any number of readers can access the collection simultaneously without affecting the consistency of the data, as the data is not modified, only read.
2. This is a single Writer. This means there can only be one writer at a time to ensure data consistency.
3. This is a greedy Writer. Writer greedy means that the Writer takes precedence over the Reader.

   Therefore, if a writer requests to use the database, all incoming readers are temporarily blocked (or locked) until they finish their work.

   However, the Writer waits until the current reader leaves. This implementation prevents the writer from starving indefinitely.

Due to the presence of this latch in MongoDB, any concurrent query can be executed without major locking conflicts.

Here the writer latch becomes interesting because in MongoDB every write operation to a single document is considered atomic. Since write operations are atomic, the writer latch is held by the MongoDB kernel only for the time required to update a single document.

Therefore, if a write operation is performed that runs slowly (for example, due to poor schema design or paging documents from disk), it is said to have latched.

Another thing to note is that, as mentioned earlier, MongoDB has a separate reader/writer latch for each database. To explain this, let's assume we have two databases, A and B.

For a write operation in database A, the writer will acquire a separate latch than for a write operation in database B.

Similarly, if multiple connections to a database are performing write operations simultaneously, the latch will be held on a per-database basis. Furthermore, these simultaneous connections will be interleaved.

Therefore, we say that locking in MongoDB is not per connection. Instead, it is per mongod.

mongod refers to the main background process of the MongoDB system, which is responsible for managing background operations such as data requests and data access.

Locking Levels in MongoDB

In MongoDB, there are four levels of locking:

1. Global level locking: This is also called instance level locking. This means all databases will be locked.
2. Database Level Locking: Only the specified database will be locked in this type of locking.
3. Collection-level locks: In MongoDB, a collection is a group of related documents (similar to a table in a traditional RDBMS). A collection-level lock handles locking a single collection.
4. Document Level Locking: A document in MongoDB can be called a record having field and value pairs. This type of locking locks only a specific document.

Locking Modes in MongoDB

In MongoDB, there are four lock modes, explained as follows.

1. R: This stands for Shared (S) lock.

   This locking mode is used for readers. Resources will be shared among readers, accessing them concurrently in this mode.

2. W: This represents an exclusive (X) lock.

   This locking mode is used by writers.

   In this mode, the resource will not be available to any other concurrent readers or writers.

3. r: This represents an Intent Shared (IS) lock.

   It is a higher level intention lock. Acquire such locks before moving to lower level locks.

   For example, if an r-lock is acquired at the database level, this means that R-locks can now be acquired at the collection and document (lower) levels.

4. w: This represents an intention exclusive (IX) lock. It is also a higher level intention lock.

Similar to how r -locks work, if a w- lock is acquired at the database level, it means that W- locks can now be acquired at the collection and document (lower) levels .

Checking the lock status in MongoDB

So, is there a way to check the status of the locks on a mongod instance? Yes, you can do so using the following method:

db.serverStatus()

You can use this method to monitor locks at various levels, for example:

1. For global level use this code db.serverStatus().globalLock.
2. For database level, use this code db.serverStatus().locks.Database.
3. For collection level, use this code db.serverStatus().locks.Collection.
4. To monitor locks in the oplog (operation log), use this code db.serverStatus().locks.oplog.

You can also use the following method:

db.currentOp()

Summarize

This article explained the concept of locking in MongoDB, its various levels and modes. We hope you were able to grasp the concepts.