CODEWITHSUNDEEP
mongodb
Ankur
Ankur

Reputation: 269

Atomicity of write in Mongo db

Mongo documentation says single document write are atomic but at another place it mentions interleaved transactions may read uncommitted data and before the writer thread has returned.

I understand that other transactions can read uncommitted data because the write may not be still committed to the journal.

But how can threads read data while the writer thread has not returned. Is it for cases when the write concern is not default?

Thanks Ankur

Upvotes: 2

Views: 440

Answers (1)

Sammaye
Sammaye

Reputation: 43884

Ok with the reference I can now get a context and tell you what this is about.

Mongo documentation says single document write are atomic

Yep

it mentions interleaved transactions may read uncommitted

Infact any read may get uncommited data. This is because MongoDB will write to the fsync queue BEFORE it writes to disk.

MongoDB can read from this fsync queue before it goes to disk, and quoting the page:

Other database systems refer to these isolation semantics as read uncommitted.

Mainly ACID databases do.

But how can threads read data while the writer thread has not returned.

Thanks to MongoDBs con-currency rules: http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-or-write-operation-ever-yield-the-lock

In short, to sum up: The write will not take exclusive lock for the duration of its running, instead it can subside (due to various rules) to a read allowing you to return data half way through a write.

This is also why you must sometimes be careful about multi-document updates and other threads of your application reading data, it may actually get one half of data that is upto date and the other half which is not.

Upvotes: 2

Related Questions