[SERVER-33218] Implement shell API for transactions Created: 09/Feb/18  Updated: 29/Oct/23  Resolved: 03/Apr/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.7.4

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

Issue Links:
Depends
is depended on by SERVER-34094 Change snapshot read tests to use mul... Closed
is depended on by SERVER-34103 Modify benchRun to use multi-statemen... Closed
is depended on by SERVER-34259 Convert existing transaction jstests ... Closed
Documented
is documented by DOCS-11540 Docs for SERVER-33218: Implement shel... Closed
Gantt Dependency
has to be done before SERVER-33921 Revisit how the mongo shell decides w... Backlog
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-03-12, Repl 2018-03-26, Repl 2018-04-09
Participants:

 Comments   
Comment by Githook User [ 02/Apr/18 ]

Author:

{'email': 'pvselvan@umich.edu', 'name': 'Pavi Vetriselvan', 'username': 'pvselvan'}

Message: SERVER-33218 implement txn shell helpers for reads and writes
Branch: master
https://github.com/mongodb/mongo/commit/94d23eaeacae39e59140b338ba7369a0f3572fc9

Comment by Spencer Brody (Inactive) [ 07/Mar/18 ]

if you call startTransaction, 'autocommit' should be implied. I don't want 'autocommit' to be exposed directly to any users.

I don't think users of the shell API should have to consume or pass around a Transaction object, but if you just want a Transaction object internal to the Session for tracking transaction-specific state, that seems reasonable.

Comment by Pavithra Vetriselvan [ 05/Mar/18 ]

We will be using the existing shell methods to start a session and get the db associated with it.

Assuming we have an initiated Replica Set, rst, this will look something like:

const testDB = rst.getPrimary().getDB("test");
const session = testDB.getMongo().startSession({casualConsistency: false});
const sessionDB = session.getDatabase("test");

From here, we can implement the `startTransaction`, `commitTransaction`, and `abortTransaction` methods. The latter two can be void functions. Since read concern and autocommit parameters can only be specified on the first statement of a transaction, we can pass these parameters into the `startTransaction` method and store these values on the current session.

The current session should probably also store information about the "state" of the transaction, in order to differentiate between a transaction that has started, is in progress, and has ended (either by committing or aborting). It might make more sense to have a Transaction object.

// Increment txnNumber on the current session and change state to "started"
// store readConcern and autocommit values
session.startTransaction({readConcern: {level: "snapshot"}, autocommit: false});

From here, we can use the DBCollection CRUD commands.

// insert command, but the format should be similar for all CRUD ops
sessionDB.collName.insert({_id: "insert-1"});

// find command
sessionDB.collName.findOne({_id: "insert-1"});

Comment by Spencer Brody (Inactive) [ 22/Feb/18 ]

pavithra.vetriselvan, before starting coding on this, please add a comment to this ticket with a proposed example of what the API would look like. This example should take the form of what it would look like to use the shell to start a session, start a transaction on that session, then do an insert, update, delete, and find as part of the transaction, and finally commit the transaction. Please use the Drivers API Design Doc as a basis for what this should look like, though note that our shell API is not currently conformant to the drivers API, so we should just do the best we can to be in line with what the drivers do without making major changes to the existing shell API.

We will eventually want to also consider findAndModify and bulk writes, but that can probably come after getting the core API for the basic CRUD ops first.

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