causal consistency

86 views

Skip to first unread message

MarkCallaghan

unread,

Dec 31, 2017, 12:41:03 PM12/31/17

to mongodb-user

I am excited about the 3.6 release but confused by the docs for causal consistency. Is this providing read-your-own writes or something stronger? Note that I am not a distributed systems guru and couldn't figure this out by reading https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/

By something stronger I mean the standard example:
1) on shard 1: remove access to photo album for my parents
2) on shard 2: publish photo of what I did on New Years Eve

In this case I don't want my parents to see the photo, but from the "Casual Consistency" docs I am not clear whether that is prevented. I think the manual needs more details to explain this. Maybe "monotonic writes" is the guarantee, but that description is brief.

On reading the spec at https://github.com/mongodb/specifications/blob/master/source/causal-consistency/causal-consistency.rst "Causal Consistency" is defined as read-your-own writes.

Wan Bachtiar

unread,

Jan 9, 2018, 5:39:52 AM1/9/18

to mongodb-user

Is this providing read-your-own writes or something stronger?

Hi Mark,

In MongoDB v3.6, client-side session support allows MongoDB drivers to specify when subsequent operations are causally related.

A driver can create a client session which in turn will have a session ID associated with it. As long as operations use the same session ID, these operations will be guaranteed to be causally consistent with each other regardless of which node is being read/written to (and any election, failure, or events on the cluster).

As described in the MongoDB Causal Consistency documentation, within a single session this should guarantee:

Read your writes
Monotonic reads
Monotonic writes
Writes follow reads

Note that applications must ensure that only a single thread at a time executes operations in a client session.

In this case I don’t want my parents to see the photo, but from the “Casual Consistency” docs I am not clear whether that is prevented

Let’s modify your example slightly. First by removing shard, as a client should be connecting to a mongos in a sharded cluster deployment.

There are two operations:

Write operation to remove access to photo album for your parents.
Write operation to publish photo of what you did on New Years Eve.

Provided that:

Both of the write operations are executed using the same session ID with writeConcern:majority (default); and
Your parents (using a different device) are accessing the photo album via an application that uses readConcern:majority

Then, your parents will not have access to your New Year’s Eve photo.