MongoDB Read/Write Locks

Question

I'm planning to create an application using nodejs that users can rate the products. From what I heard locks are different in mongodb than mySql.

I'm worried that if let's say 10 users vote on a product at a same time, Mongodb can't handle it and the result other users see is not correct.

I looked at similar questions but I'm still confused! Is mongodb a good choice or should I just use Mysql? I'd appreciate your help

Answer 1

Locking is described in this Concurrency FAQ in the MongoDB documentation. In particular:

MongoDB uses a readers-writer lock that allows concurrent reads access to a database but gives exclusive access to a single write operation.

When a read lock exists, many read operations may use this lock. However, when a write lock exists, a single write operation holds the lock exclusively, and no other read or write operations may share the lock.

Locks are “writer greedy,” which means write locks have preference over reads. When both a read and write are waiting for a lock, MongoDB grants the lock to the write.

So in regards to your statement:

Mongodb can't handle it and the result other users see is not correct.

MongoDB employs a database-wide lock that prevents reads/writes while a write operation is being performed somewhere in the database. By the looks of this JIRA item, this will be reduced to a collection-level lock in the future (right now it's just in a development version). Also, because of the "writer greedy" approach, if multiple writes are waiting to be performed, they will be done before any reads, so your concern shouldn't be an issue.

Answer 2

Any write operation to a single document is guaranteed to be atomic. It will either totally succeed, or not at all, and a client requesting that same document is guaranteed to get a copy of that same document that is in a consistent state.

For bulk operations, this is not the case by default. Normally, if you update 10 documents in a single operation, then it's possible that other operations may interleave between the updates. You can isolate the operation by using the $isolated operator to ensure that nobody else can view that set of documents in an inconsistent state.

In a more general sense, MongoDB uses a writer-greedy readers-writer lock so that you can be pretty sure that if client A updates a document right before client B reads it, then B will see writer A's updates. Some of that will come down to the implementation of the driver and how you use it, of course, but that's true with any database.

Distributed environments

The above applies only if your talking about a single instance. Once you have a distributed mongo setup, then we start talking CAP theorem. One of the great features of MongoDB is how well is scales to deal with huge data sets. This is typically accomplished using either sharding, replica-sets, or both. In either of these scenarios, MongoDB is said to be eventually consistent. In a distributed setup, it may be possible for client B to read a document that is missing client A's update, because MongoDB chooses Availability over Consistency. Eventually, all those inconsistencies will get ironed out, and in practice it's usually consistent enough for most use cases. But it's can't make any guarantees when it's setup in a distributed environment.