Skip to content

Update read-concern.txt #3266

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.

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

Merged
merged 1 commit into from
Mar 18, 2018
Merged
Changes from all commits
Commits
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
12 changes: 6 additions & 6 deletions source/reference/read-concern.txt
Original file line number Diff line number Diff line change
Expand Up @@ -136,16 +136,16 @@ The following read concern levels are available:

.. versionadded:: 3.6

MongoDB introduces the ``afterClusterTime`` option that can be set by
the drivers.
MongoDB 3.6 introduces the ``afterClusterTime`` option that can be set by
the drivers. To satisfy a read request with an ``afterClusterTime`` value of ``T`` a mongod must perform the request after its opLog reaches time ``T``. If its opLog has not reached time ``T`` the mongod must wait to service the request.

Read operations with a specified ``afterClusterTime``
return data that meet both the :ref:`read concern level <read-concern-levels>`
requirement and the specified ``afterClusterTime`` requirement.
requirement and the specified ``afterClusterTime`` requirement.

.. important::

Do not manually set the ``afterClusterTime``. MongoDB drivers set
Do not manually set ``afterClusterTime``. MongoDB drivers set
this value automatically for operations associated with
causally consistent sessions.

Expand All @@ -160,8 +160,8 @@ and :readconcern:`"majority"` read concern levels:
readConcern: { level: <"majority"|"local"> , afterClusterTime: <Timestamp> }

For read operations not associated with causally consistent sessions,
i.e. where the ``afterClusterTime`` is unset, reads against secondary members
have the default read concern level: :readconcern:`"available"`.
i.e. where ``afterClusterTime`` is unset, reads against secondary members
have the default read concern level: :readconcern:`"available"`, meaning that queries will return the instance’s most recent data. :readconcern:`"available"` provides no guarantee that data has been written to a majority of the replica set members. It might be rolled back.

.. _read-concern-storage-engine-drivers:

Expand Down