[SERVER-32517] Parse readConcern snapshot and atClusterTime Created: 02/Jan/18  Updated: 30/Oct/23  Resolved: 23/Jan/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.7.2

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-11245 Docs for SERVER-32517: Parse readConc... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2018-01-15, Storage 2018-01-29
Participants:

 Description   

Parse the following new syntax for readConcern:

{readConcern: {level: "snapshot"}}
{readConcern: {atClusterTime: <timestamp>}}

Parsing for snapshot:

  • Add level "snapshot" to the readConcern interface.
    • Add "snapshot" level definition to the ReadConcernArgs class.
    • Parse in ReadConcernArgs::initialize().
  • Update ReplicationCoordinatorImpl::_validateReadConcern() to allow the readConcern level snapshot with afterClusterTime.
  • Return an error if the mongod is not a member of a replica set.
  • Support readConcern level snapshot for the commands aggregate, count, distinct, group, geoNear, geoSearch, find, insert, update, delete, findAndModify.
  • Ban on mongos.

Parsing for atClusterTime:

  • Add readConcern parsing / initialization components (ReadConcernArgs::initialize()).
    • Remove the "testMode" check.
    • Error if the level is not snapshot.
    • Error if paired with afterOpTime or afterClusterTime.
  • Update ReplicationCoordinatorImpl::_validateReadConcern() to check that the readConcern level is snapshot if atClusterTime is provided.


 Comments   
Comment by Githook User [ 23/Jan/18 ]

Author:

{'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}

Message: SERVER-32517 Parse readConcern snapshot and atClusterTime
Branch: master
https://github.com/mongodb/mongo/commit/a98d497c957dc2da7d29c37be9809ace992ef946

Comment by Tess Avitabile (Inactive) [ 04/Jan/18 ]

Sure, we can hold off on the shell API for snapshot reads. It's not clear to me from the Local Snapshot Reads scope whether we will support readConcern:snapshot on writes outside of transactions. We are also going to discuss whether we will support any use of readConcern:snapshot outside of transactions.

Is there any reason to hold off on accepting readConcern level snapshot for write commands in the server?

Comment by Spencer Brody (Inactive) [ 04/Jan/18 ]

Hmm... are we planning to support readConcern on regular, non-transactional write operations? If the answer is no, as I suspect it is, then it may make sense to hold off on designing the shell API for snapshot reads until we have a better idea what the shell API for transactions will look like. For instance, I could easily foresee a design where running a transaction in the shell looks something like this:

db.foo.beginTransaction({readConcern: {level: 'snapshot'}});
db.foo.insert(...);
db.foo.update(...);
...
db.foo.commitTransaction();

In that world, I'm not sure that the individual write operations in the shell would ever need to take a readConcern argument at all.

Comment by Tess Avitabile (Inactive) [ 04/Jan/18 ]

Proposal for new syntax for shell helpers. This matches the placement of writeConcern. milkie, james.wahlin, spencer, please take a look.

Operations:

db.coll.insert(<doc>, {readConcern: {...}});
db.coll.findAndModify({query: <query>, update: <update>, ... , readConcern: {...});
db.coll.update(<predicate>, <update>, {readConcern: {...}});
db.coll.remove(<predicate>, {readConcern: {...}});

CRUD API:

db.coll.bulkWrite([
    {insertOne: {..., readConcern: {...}}},
    {updateOne: {..., readConcern: {...}}},
    {updateMany: {..., readConcern: {...}}},
    {replaceOne: {..., readConcern: {...}}},
    {deleteOne: {..., readConcern: {...}}},
    {deleteMany: {..., readConcern: {...}}},
]);
db.coll.findOneAndUpdate(
<filter>, <update>, {readConcern: {...}}
);
db.coll.findOneAndReplace(
<filter>, <replacement>, {readConcern: {...}}
);
db.coll.insertOne(<doc>, {readConcern: {...}});
db.coll.updateOne(<filter>, <update>, {readConcern: {...}});
db.coll.updateMany(<filter>, <update>, {readConcern: {...}});
db.coll.replaceOne(<filter>, <replacement>, {readConcern: {...}});
db.coll.deleteOne(<filter>, {readConcern: {...}});
db.coll.deleteMany(<filter>, {readConcern: {...}});

Bulk write API: (

var bulk = db.coll.initializeUnorderedBulkOp();
bulk.find({...}).updateOne/update/removeOne/remove();
bulk.insert({...})
bulk.execute(<writeConcern>, <readConcern>);

Generated at Thu Feb 08 04:30:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.