Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Read-your-own-writes consistency in Mongodb

first, here is what is said in Pymongo Documentation

By default, PyMongo starts a request for each thread when the thread first runs an operation on MongoDB. This guarantees **read-your-writes consistency. Within a request, the thread will continue to use the same socket exclusively, and no other thread will use this socket, until the thread calls end_request() or it terminates. At that point, the socket is returned to the connection pool for use by other threads.

so when using an async library to Mongodb (like Asyncmongo, Motor), will the user have a consistency like the one in blocking calls or an eventual consistency?

like image 746
Abdelouahab Pp Avatar asked Sep 22 '12 14:09

Abdelouahab Pp


People also ask

How do you ensure consistency in MongoDB?

MongoDB is strongly consistent by default - if you do a write and then do a read, assuming the write was successful you will always be able to read the result of the write you just read. This is because MongoDB is a single-master system and all reads go to the primary by default.

What is read after write consistency?

Read-after-write consistency is the ability to view changes (read data) right after making those changes (write data). For example, if you have a user profile and you change your bio on the profile, you should see the updated bio if you refresh the page. There should be no delay during which the old bio shows up.

Why MongoDB is not consistent?

It further says If you optionally enable reading from the secondaries then MongoDB becomes eventually consistent where it's possible to read out-of-date results. It means mongo may not be be consistent with master/slaves(provided i do not configure write to all nodes before return).

Does MongoDB have tunable consistency?

To provide users with a set of tunable consistency options, MongoDB exposes writeConcern and readConcern levels, which are parameters that can be set on each database op- eration. writeConcern specifies what durability guarantee a write must satisfy before being acknowledged to a client.


1 Answers

There are a couple of points about this question.

  1. You aren't guaranteed to have read-after-write consistency unless you're using either "safe=true", "w=1" (or greater) or "j=true" with your write. You can either include these as part of the insert() or update() commands, or else use set_lasterror_options() to set these options for the connection, database, or collection that you're using.

  2. If you're allowing reads from secondary nodes, (e.g. a ReadPreference other than PRIMARY), then you will not get read-after-write semantics, but only eventual consistency.

  3. If you are using a ReadPreference of PRIMARY and you're setting the appropriate lasterror options, then you're guaranteed to get read-after-write semantics on all operations that use the same socket, that is, the same thread.

  4. If you're using multiple threads, and you are NOT reading from secondary nodes, then you're guaranteed to get read-after-write consistency as long as you issue the read in the second thread after the write completes in the first thread. You can use standard thread synchronization primitives to assure this.

like image 131
William Z Avatar answered Sep 22 '22 14:09

William Z