Skip to content

Kyle K's suggestions #2794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Kyle K's suggestions #2794

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions source/reference/read-concern.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,9 +52,9 @@ The following read concern levels are available:
* - .. readconcern:: "linearizable"

- The query returns data that reflects all successful writes
issued with a :writeconcern:`"majority"` *and* acknowledged
issued with a write concern of :writeconcern:`"majority"` *and* acknowledged
prior to the start of the read operation. Linearizable read
concern returns data that cannot be rolled back. You can specify
concern returns data that will never be rolled back. You can specify
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Eric --
just wanted to double check. Given that we now state that possibly, writes issued with "w: majority" write concern could roll back, is the above still true? Wasn't sure what the mechanics behind linearizable reads are.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do we say w:majority write concern writes could roll back? I'll check everything for continuity.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://docs.mongodb.com/manual/reference/write-concern/#acknowledgement-behavior
https://docs.mongodb.com/manual/reference/replica-configuration/#rsconf.writeConcernMajorityJournalDefault
https://docs.mongodb.com/manual/core/replica-set-rollbacks/#avoid-replica-set-rollbacks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right. The Note applies to this blurb about linearizable reads as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could I then tweak to:
For replica sets that run with writeConcernMajorityJournalDefault set to true, linearizable read concern returns data that will never be rolled back.

With writeConcernMajorityJournalDefault set to false, MongoDB will not wait for w: "majority" writes to be durable before acknowledging the writes. As such, "majority" write operations could possibly roll back in the event of a loss of a replica set member.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect.

linearizable read concern for read operations on the
:replstate:`primary <PRIMARY>` only.

Expand Down