MongoDB Transactions and ACID Compliance Flashcards

What is the 'snapshot' isolation level provided by MongoDB transactions?

Answer: All reads within the transaction see a consistent snapshot of data as it existed at the transaction's start time

Snapshot isolation ensures all read operations within a transaction see a consistent view of the data as it existed at the logical transaction start time. This means the transaction is isolated from any committed or uncommitted changes made by concurrent transactions during its execution.

In MongoDB 4.2+, what was extended regarding multi-document transactions?

Answer: Support for multi-document transactions on sharded clusters

MongoDB 4.2 extended multi-document ACID transactions to sharded clusters, which were previously only available for replica sets (introduced in 4.0). This allows atomic operations spanning multiple documents across multiple shards with full ACID guarantees.

What does the ErrorLabel 'UnknownTransactionCommitResult' indicate?

Answer: The commit result is unknown due to network error; the application should retry the commitTransaction() call

'UnknownTransactionCommitResult' means a network error occurred during the commitTransaction() call and it is unknown whether the commit succeeded. The application should retry only the commit (not the entire transaction) — MongoDB's commit is idempotent, so retrying is safe.

Which MongoDB feature allows you to perform read and write operations atomically within a single pipeline stage?

Answer: findAndModify / findOneAndUpdate

findAndModify (and its driver equivalents findOneAndUpdate, findOneAndReplace, findOneAndDelete) atomically find and modify a single document without needing an explicit multi-document transaction. These are atomic at the single-document level and are preferred for simple atomic operations.

What is the purpose of the retryWrites connection string option in MongoDB?

Answer: Automatically retrying certain idempotent write operations once after transient network failures

retryWrites=true (the default in modern drivers) enables automatic retry of certain idempotent write operations (insert, update, delete, findAndModify) exactly once if they fail due to transient network errors or replica set elections. It does not apply to multi-statement transactions.

Why is it an anti-pattern to use MongoDB transactions for every write operation?

Answer: Transactions introduce latency overhead; MongoDB's document model allows many multi-entity operations to be atomic via embedding, eliminating the need for transactions

MongoDB's document model encourages embedding related data so that operations affecting multiple 'entities' can be done in a single atomic document write. Transactions add significant overhead (locking, oplog growth, coordination). The best practice is to model data to avoid transactions and only use them when truly necessary.