Monotonic reads in causal consistent sessions and read concern "local"
Lia
I have a question about the causal consistency guarantees of MongoDB 3.6.
The documentation states causal consistent sessions/client sessions guarantee monotonic reads.
I've tested this by repeatedly reading the value of a data item and checking whether the currently read value is greater or equal than the previously read value (in pseudocode):
function checkMonotonicReads (int numberOfValues) {
firstReadValue = read (key)
for i = 1 to numberOfValues do
newReadValue = read (key)
if newReadValue >= firstReadValue then
log (monotonic reads complied)
else
log (monotonic reads violated)
}Another client updates the value of the data element in parallel:
function write (int numberOfValues) {
for i = 1 to numberOfValues do
write (key, i)
}According to the documentation to ensure causal consistency the read concern level can be set as follows:
readConcern: {level: <"majority" | "local">, afterClusterTime: <timestamp>}Accordingly, I ran my tests with both the read concern level "majority" and "local".
I used MongoDB 3.6 as a replica set consisting of 3 nodes inside Docker and used the Java driver 3.6.0.
I used the write concern levels 1, 2, 3 and "majority" and the read preference "secondary".
The read operations were performed in a client session.
In the tests with the read concern level "local" I have found violations of the monotonic read guarantees. So for example the value 5 was read first and afterwards the value 3 was read.
I guess that this can be traced back to the read concern level "local" (?)
But at this point the documentation seems contradictory to me: on the one hand, in client sessions monotonic reads are guaranteed (with the read concern "majority" or "local").
On the other hand, "local" returns the most recent value of the requested instance with no guarantee that this value has already been written to a majority of nodes.
So the scenario described above can occur.
What takes precedence? The guarantees of causal consistent sessions or the limitations of the read concern level "local"? Based on the results of my tests
I think that "local" predominates and invalidates the causal consistency guarantees in client sessions.
If my guess is correct I think the documentation should be adapted and clarified in this regard.
If I am wrong, where is my mistake?
Best regards
Kevin Adistambha
Hi
If I understand correctly, your test has these two parallel parts:
- one client is reading a document (which presumably was modified to check that the read is causally consistent)
- one client is modifying the same documents that the first client is reading
Is this the correct understanding of your test setup?
If it is correct, the first thing that needed to be clear is that causal consistency guarantees are valid only for a single session. That is, if you have another parallel session going on that modifies the documents at the same time, the session will see the parallel update. I believe this is what you’re seeing.
This is mentioned in a note in the page you linked: “Operations within a client session are not isolated from operations outside the session.”
The main feature of causal consistency is to be able to provide causality guarantees in a replica set, e.g. when you’re writing to the primary, and reading from a secondary. Previously, even if you do your writes with w: majority and reads with readConcern: majority, there is no guarantee the causality of your reads & writes. Causal consistency provides this guarantee across the replica set.
In the tests with the read concern level “local” I have found violations of the monotonic read guarantees. So for example the value 5 was read first and afterwards the value 3 was read.
Assuming 5 is supposed to be after 3, this would be a violation if the read and writes are performed within a single, causally consistent session. If 3 was written from outside the session, it is not a violation because the guarantee is not valid if another thread modifies the document.
What takes precedence? The guarantees of causal consistent sessions or the limitations of the read concern level “local”?
If the session was created with causal consistency, then the causality guarantees would take precedence over read concerns. Note that within a session, you can specify different read concerns for different read operations.
You may find the following links interesting:
- New Driver Features for MongoDB 3.6, specifically the “Causal Consistency” section.
- Causal Consistency Specification, which describes in detail how causal consistency is implemented.
Best regards
Kevin
Lia
Thank you for your answer.
Is this the correct understanding of your test setup?
Yes, your understanding is correct.
I think I found the problem of my implementation. Although I perform all read and write operations within the same client session I use two threads: one for the writer and one for the reader. As I just read in the documentation this is not possible for causal consistent sessions:
Applications must ensure that only one thread at a time executes these operations in a client session.
So I think this is why I see violations of monotonic reads.
Best regards