Why using Locking in MongoDB?

Question

MoongoDB is from the NoSql era, and Lock is something related to RDBMS? from Wikipedia:

Optimistic concurrency control (OCC) is a concurrency control method for relational database management systems...

So why do i find in PyMongo is_locked , and even in driver that makes non-blocking calls, Lock still exists, Motor has is_locked.

Answer 1

MongoDB implements a Database level locking system. This means that operations which are not atomic will lock on a per database level, unlike SQL whereby most techs lock on a table level for basic operations.

In-place updates only occur on certain operators - $set being one of them, MongoDB documentation did used to have a page that displayed all of them but I can't find it now.

MongoDB currently implements a read/write lock whereby each is separate but they can block each other.

Locks are utterly vital to any database, for example, how can you ensure a consistent read of a document if it is currently being written to? And if you write to the document how do you ensure that you only apply that single update at once and not multiple updates at the same time?

I am unsure how version control can stop this in CouchDB, locks are really quite vital for a consistent read and are separate to version control, i.e. what if you wish to apply a read lock to the same version or read a document that is currently being written to a new revision? You will obviously see a lock queue appear. Even though version control might help a little with write lock saturation there will still be a write lock and it will still need to work on a level.

As for concurrency features; MongoDB has the ability (for one), if the data is not in RAM, to subside a operation for other operations. This means that locks will not just sit there waiting for data to be paged in and other operations will run in the mean time.

As a side note, MongoDB actually has more locks than this, it also has a JavaScript lock which is global and blocking, it does not have the normal concurrency features of regular locks.

and even in driver that makes non-blocking calls

Hmm I think you might be confused by what is meant as a "non-blocking" application or server: http://en.wikipedia.org/wiki/Non-blocking_algorithm

Answer 2

NoSQL does not mean automatically no locks. There always some operations that do require a lock.

For example building of index

And official MongoDB documentation is a more reliable source than wikipedia(none offense meant to wikipedia :) )

http://docs.mongodb.org/manual/faq/concurrency/

Answer 3

Mongo does in-place updates, so it needs to lock in order to modify the database. There are other things that need locks, so read the link @Tigra provided for more info.

This is pretty standard as far as databases and it isn't an RDBMS-specific thing (Redis also does this, but on a per-key basis).

There are plans to implement collection-level (instead of database-level) locking: https://jira.mongodb.org/browse/SERVER-1240

Some databases, like CouchDB, get around the locking problem by only appending new documents. They create a new, unique revision id and once the document is finished writing, the database points to the new revision. I'm sure there's some kind of concurrency control when changing which revision is used, but it doesn't need to block the database to do that. There are certain downsides to this, such as compaction needing to be run regularly.