Commit and abort behavior in MongoDB - Time & Space Complexity

Time Complexity: Commit and abort behavior

O(n)

Understanding Time Complexity

When working with transactions in MongoDB, it is important to understand how the time to commit or abort changes as the amount of work grows.

We want to know how the cost of finishing or canceling a transaction scales with the number of operations inside it.

Scenario Under Consideration

Analyze the time complexity of the following MongoDB transaction commit and abort code.

const session = client.startSession();
session.startTransaction();

try {
  for (let i = 0; i < n; i++) {
    await collection.insertOne({ item: i }, { session });
  }
  await session.commitTransaction();
} catch (error) {
  await session.abortTransaction();
} finally {
  await session.endSession();
}
    

This code inserts n documents inside a transaction, then tries to commit. If something goes wrong, it aborts the transaction.

Identify Repeating Operations

Look for repeated actions that take time.

• Primary operation: Inserting n documents inside the transaction.
• How many times: The insert runs n times, once per document.
• Commit/abort: Happens once after all inserts or on error.

How Execution Grows With Input

As the number of documents n grows, the total work grows mostly because of the inserts.

Input Size (n)	Approx. Operations
10	About 10 inserts + 1 commit or abort
100	About 100 inserts + 1 commit or abort
1000	About 1000 inserts + 1 commit or abort

Pattern observation: The total time grows roughly in direct proportion to n because each insert takes time, but commit or abort happens once.

Final Time Complexity

Time Complexity: O(n)

This means the time to complete the transaction grows linearly with the number of operations inside it.

Common Mistake

[X] Wrong: "Commit or abort takes the same time no matter how many operations are in the transaction."

[OK] Correct: Commit and abort must finalize all operations, so their time depends on how many operations were done inside the transaction.

Interview Connect

Understanding how transaction commit and abort scale helps you reason about database performance and reliability in real projects.

Self-Check

"What if we batch multiple inserts into one operation inside the transaction? How would the time complexity change?"

Practice

1. What happens when you commit a transaction in MongoDB?

easy

A. All changes made during the transaction are saved permanently.

B. All changes made during the transaction are discarded.

C. The transaction is paused and can be resumed later.

D. Only some changes are saved, others are lost.

Solution

1. Step 1: Understand commit behavior

   Committing a transaction means saving all changes made during that transaction permanently to the database.

2. Step 2: Compare with abort

   Unlike abort, which cancels changes, commit finalizes them.

3. Final Answer:

   All changes made during the transaction are saved permanently. -> Option A

4. Quick Check:

   Commit = Save changes [OK]

Hint: Commit means save all changes made in the transaction [OK]

Common Mistakes:

• Confusing commit with abort
• Thinking commit only saves some changes
• Believing commit pauses the transaction

2. Which of the following is the correct syntax to abort a transaction in MongoDB using the shell?

easy

A. transaction.abort()

B. session.abortTransaction()

C. db.abort()

D. session.commit()

Solution

1. Step 1: Recall MongoDB transaction abort syntax

   The correct method to abort a transaction is session.abortTransaction().

2. Step 2: Eliminate incorrect options

   session.commit() is invalid, db.abort() and transaction.abort() are not valid MongoDB shell commands.

3. Final Answer:

   session.abortTransaction() -> Option B

4. Quick Check:

   Abort transaction = session.abortTransaction() [OK]

Hint: Abort transaction uses session.abortTransaction() method [OK]

Common Mistakes:

• Using commit() instead of abortTransaction()
• Trying to abort with db.abort() which doesn't exist
• Confusing transaction object with session

3. Consider this MongoDB transaction code snippet:

const session = client.startSession();
session.startTransaction();
await collection.insertOne({name: 'Alice'}, {session});
await session.abortTransaction();
const count = await collection.countDocuments({name: 'Alice'});
console.log(count);

What will be printed?

medium

A. 0

B. 1

C. undefined

D. Error

Solution

1. Step 1: Analyze transaction operations

   The document insertion happens inside a transaction that is aborted immediately after.

2. Step 2: Understand abort effect on data

   Aborting the transaction cancels the insert, so the document is not saved.

3. Final Answer:

   0 -> Option A

4. Quick Check:

   Abort cancels insert, count = 0 [OK]

Hint: Aborted inserts do not persist, count remains zero [OK]

Common Mistakes:

• Assuming insert stays after abort
• Expecting count to be 1
• Thinking abort throws error

4. You wrote this MongoDB transaction code but it throws an error:

const session = client.startSession();
session.startTransaction();
await collection.insertOne({item: 'book'}, {session});
session.commitTransaction();
session.endSession();

What is the likely cause of the error?

medium

A. insertOne() is missing session option

B. startTransaction() is called twice

C. Missing await before commitTransaction()

D. endSession() must be called before commitTransaction()

Solution

1. Step 1: Check async calls in transaction

   commitTransaction() returns a promise and must be awaited to complete properly.

2. Step 2: Identify missing await causes error

   Without await, the code may proceed before commit finishes, causing errors.

3. Final Answer:

   Missing await before commitTransaction() -> Option C

4. Quick Check:

   Async commit needs await [OK]

Hint: Always await commitTransaction() to avoid errors [OK]

Common Mistakes:

• Not awaiting commitTransaction()
• Calling startTransaction() multiple times
• Calling endSession() too early

5. You want to update two documents atomically in MongoDB. You start a transaction, update the first document, then update the second. If the second update fails, what should you do to ensure no partial changes remain?

hard

A. Manually delete the first update after failure.

B. Commit the transaction to save the first update only.

C. Ignore the failure and continue.

D. Abort the transaction to cancel all changes.

Solution

1. Step 1: Understand atomicity in transactions

   Transactions ensure all-or-nothing changes. If one update fails, the whole transaction should be canceled.

2. Step 2: Apply abort to cancel partial changes

   Aborting the transaction cancels all changes, preventing partial updates.

3. Final Answer:

   Abort the transaction to cancel all changes. -> Option D

4. Quick Check:

   Fail in transaction = abort all changes [OK]

Hint: Abort transaction to avoid partial updates on failure [OK]

Common Mistakes:

• Committing partial updates
• Trying to manually fix partial changes
• Ignoring failure and continuing