1

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.

Abdelouahab Pp
  • 4,252
  • 11
  • 42
  • 65

3 Answers3

3

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/

Tigra
  • 2,611
  • 20
  • 22
2

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.

beatgammit
  • 19,817
  • 19
  • 86
  • 129
  • so every DBMS gets its own technique to reduce the lock? – Abdelouahab Pp Mar 23 '13 at 00:30
  • 1
    @AbdelouahabPp - I'm not a DB expert, but it seems to depend on how the database is implemented. Locking is often a tradeoff to guarantee faster queries (slow write vs slow read). Ask at http://dba.stackexchange.com to get expert insight. – beatgammit Mar 23 '13 at 00:40
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

Sammaye
  • 43,242
  • 7
  • 104
  • 146
  • sorrybut i dont follow you in the non blocking and locking databases, does non blocking is useless when the database locks itself? – Abdelouahab Pp Mar 24 '13 at 00:12
  • 1
    @AbdelouahabPp Non-blocking is a feature of the application/server, it isn't useless because it is concerned with how the application runs and how it processes its own data. Hmmm, imagine two PHP processes contesting for the same script, even though you don't see it there is a slight "lock" delay on the spinning up of a new script which is already running, in a non-blocking app this would not be the case, as an example – Sammaye Mar 24 '13 at 03:33
  • so i guess that if process1 tries to make a DB call and finds that mongodb locked it leaves it immediatly saying something like: hey, process2, now it's your turn to try? – Abdelouahab Pp Mar 24 '13 at 13:41
  • 1
    @AbdelouahabPp Depends on the language but technically yes, or rather all processes will send to the database at once and mongodb will do its own internal shuffling of the requests via its concurrency features. – Sammaye Mar 24 '13 at 14:10
  • what about python, it has a driver called Motor which works with Tornado, and it is a non blocking driver, so it will 'back' and not bloack ressources when it find that mongod is locked? – Abdelouahab Pp Mar 24 '13 at 15:31
  • 1
    @AbdelouahabPp I believe so, theortically, I must admit I haven't used tornado or python or motor so I am guessing a little here, but the nature of non-blocking should hold true there. – Sammaye Mar 25 '13 at 13:43
  • the nature of nonblocking here is the same, you make a callback and wait. – Abdelouahab Pp Mar 25 '13 at 14:28