1

The MongoDB 3.0 FAQ states that:

MongoDB uses reader-writer locks that allow concurrent readers shared access to a resource, such as a database or collection, but give exclusive access to a single write operation.

I have understood that the read operation will be blocked until the write commits the changes to the main memory.

My question is:

Instead of getting blocked by the write lock, is there any way to allow the read operation to obtain the document (row) state that existed prior to the modification?

I know that the data prior to the write operation will be inconsistent (stale) data, but that is ok for me.

Community
  • 1
  • 1
Rutvij Ravi
  • 11
  • 2
  • You could read from a secondary, but aside from that I do not think so – Sammaye May 23 '15 at 13:18
  • @Sammaye Is there something to do at client side to "read from a secondary" (implying we _know_ that we would block) or does it append automagically ? – Sylvain Leroux May 23 '15 at 14:27
  • You would set read preference within the driver to be secondaryPreferred http://docs.mongodb.org/manual/core/read-preference/ – Sammaye May 23 '15 at 15:48
  • But now that I read your question I think you do not quite understand on what level locks in MongoDB work and how they work and in turn how reading from secondary would work. I would srtongly recommend you read more of the mongodb docs and you search around a bit, for example one good answer here is: http://stackoverflow.com/a/17459488/383478 – Sammaye May 23 '15 at 15:50
  • possible duplicate of [To what level does MongoDB lock on writes? (or: what does it mean by "per connection"](http://stackoverflow.com/questions/17456671/to-what-level-does-mongodb-lock-on-writes-or-what-does-it-mean-by-per-connec) – Sylvain Leroux May 23 '15 at 16:42

0 Answers0