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?
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.
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.
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).
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.
There are a couple of points about this question.
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With