MongoDB MongoDB Transactions and ACID Compliance 1 — Questions and Answers
Question 1: In which MongoDB version were multi-document ACID transactions introduced for replica sets?
- MongoDB 3.6
- MongoDB 4.0 (Correct answer)
- MongoDB 4.2
- MongoDB 5.0
Correct answer: MongoDB 4.0
Multi-document ACID transactions for replica sets were introduced in MongoDB 4.0. MongoDB 4.2 extended transactions to sharded clusters. Prior to 4.0, atomicity was guaranteed only at the single-document level.
Question 2: What does ACID stand for in the context of database transactions?
- Atomic, Consistent, Isolated, Durable (Correct answer)
- Automated, Concurrent, Indexed, Distributed
- Associative, Consistent, Incremental, Distributed
- Atomic, Cached, Isolated, Dynamic
Correct answer: Atomic, Consistent, Isolated, Durable
ACID stands for Atomicity (all operations succeed or all are rolled back), Consistency (data moves from one valid state to another), Isolation (concurrent transactions don't interfere), and Durability (committed transactions persist even after system failure).
Question 3: How do you start a multi-document transaction in MongoDB using the Node.js driver?
- db.beginTransaction()
- session.startTransaction() (Correct answer)
- client.openTransaction()
- db.collection.lockWrite()
Correct answer: session.startTransaction()
To use multi-document transactions in MongoDB, you first start a client session with client.startSession(), then call session.startTransaction(). All operations within the transaction must pass the session object, and you call session.commitTransaction() or session.abortTransaction() to finalize.
Question 4: What happens to a MongoDB transaction if commitTransaction() is not called before the session times out?
- The transaction is committed automatically
- The transaction is rolled back and all changes are discarded (Correct answer)
- The transaction is saved as a pending transaction
- An error is thrown and the application must retry
Correct answer: The transaction is rolled back and all changes are discarded
If a transaction is not committed before the session or transaction timeout (default 60 seconds), MongoDB automatically aborts and rolls back the transaction. All write operations within the transaction are discarded as if they never occurred.
Question 5: Which read concern is required to read the latest majority-committed data within a MongoDB transaction?
- local
- available
- snapshot (Correct answer)
- majority
Correct answer: snapshot
Transactions default to 'snapshot' read concern, which provides a consistent snapshot of the data as of the transaction's start time. 'snapshot' read concern ensures that all reads within a transaction see the same consistent view of the data.
Question 6: What is the recommended write concern for MongoDB transactions to ensure durability?
- { w: 0 }
- { w: 1 }
- { w: 'majority' } (Correct answer)
- { w: 'all' }
Correct answer: { w: 'majority' }
{ w: 'majority' } is the recommended write concern for transactions. It ensures the committed transaction has been written to a majority of replica set members, providing durability. Using w: 1 risks rollback if the primary fails before the secondary replicates the commit.
In which MongoDB version were multi-document ACID transactions introduced for replica sets?