Consider a MongoDB transaction that inserts a document into the users collection and then commits successfully. What will be the result of querying users after the commit?
session.startTransaction();
db.users.insertOne({name: 'Alice'}, {session});
session.commitTransaction();
db.users.find({name: 'Alice'}).toArray();Think about what happens to data after a commit in a transaction.
After a successful commit, the inserted document becomes visible outside the transaction, so querying returns the new document.
A transaction inserts a document into the orders collection but then aborts. What will be the result of querying orders for that document?
session.startTransaction();
db.orders.insertOne({orderId: 123}, {session});
session.abortTransaction();
db.orders.find({orderId: 123}).toArray();Consider what aborting a transaction does to the changes made inside it.
Aborting a transaction discards all changes made during it, so the inserted document is not saved.
Identify the option that uses correct syntax to start a session, begin a transaction, insert a document, and commit the transaction.
Check the correct method names and usage of session in operations.
Option B correctly uses startTransaction(), passes the session to the insert operation, commits, and ends the session.
Given the code below, why does the transaction fail to commit?
const session = client.startSession(); session.startTransaction(); db.collection('inventory').updateOne({sku: 'abc'}, {$inc: {qty: -1}}, {session}); session.commitTransaction(); session.endSession();
Think about how MongoDB knows which operations belong to the transaction.
Operations must include the session option to be part of the transaction. Without it, the update runs outside the transaction, causing commit failure.
In a multi-document transaction that modifies several collections, what happens if the transaction aborts?
Recall the atomicity property of transactions.
MongoDB transactions are atomic; aborting rolls back all changes made during the transaction across all collections.