Bird
Raised Fist0
MongoDBquery~10 mins

Read concern and write concern in transactions in MongoDB - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to start a transaction with a read concern of 'majority'.

MongoDB
const session = client.startSession();
session.startTransaction({ readConcern: { level: '[1]' } });
Drag options to blanks, or click blank then click option'
Amajority
Blinearizable
Clocal
Davailable
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'local' which reads from the node's local data and may not be majority committed.
Using 'available' which is not a valid read concern level.
2fill in blank
medium

Complete the code to set the write concern to 'w: 1' in a transaction.

MongoDB
session.startTransaction({ writeConcern: { w: [1] } });
Drag options to blanks, or click blank then click option'
Amajority
B0
C1
Dall
Attempts:
3 left
💡 Hint
Common Mistakes
Using '0' which means no acknowledgment.
Using 'all' which is not a valid write concern value.
3fill in blank
hard

Fix the error in the transaction options to correctly specify read concern level.

MongoDB
session.startTransaction({ readConcern: { level: '[1]' } });
Drag options to blanks, or click blank then click option'
AmajorityLevel
BMAJORITY
Cmajor
Dmajority
Attempts:
3 left
💡 Hint
Common Mistakes
Using uppercase letters which cause errors.
Using incomplete or incorrect words.
4fill in blank
hard

Fill both blanks to start a transaction with read concern 'snapshot' and write concern 'majority'.

MongoDB
session.startTransaction({ readConcern: { level: '[1]' }, writeConcern: { w: '[2]' } });
Drag options to blanks, or click blank then click option'
Asnapshot
Blocal
Cmajority
D1
Attempts:
3 left
💡 Hint
Common Mistakes
Mixing read concern levels that are not supported in transactions.
Using write concern values that are not strings.
5fill in blank
hard

Fill all three blanks to start a transaction with read concern 'local', write concern '1', and specify a max commit time of 1000 milliseconds.

MongoDB
session.startTransaction({ readConcern: { level: '[1]' }, writeConcern: { w: '[2]' }, maxCommitTimeMS: [3] });
Drag options to blanks, or click blank then click option'
Amajority
B1
C1000
Dlocal
Attempts:
3 left
💡 Hint
Common Mistakes
Using string quotes around maxCommitTimeMS value.
Confusing read concern levels.

Practice

(1/5)
1. What does readConcern control in a MongoDB transaction?
easy
A. How fresh or confirmed the data you read is during the transaction
B. How many servers confirm your data changes before commit
C. The speed of the transaction execution
D. The size of the data being written

Solution

  1. Step 1: Understand the role of readConcern

    Read concern defines the level of isolation and freshness of data read during a transaction.
  2. Step 2: Differentiate from writeConcern

    Write concern controls confirmation of writes, not reads.
  3. Final Answer:

    How fresh or confirmed the data you read is during the transaction -> Option A
  4. Quick Check:

    readConcern = data freshness [OK]
Hint: Read concern is about data freshness, write concern is about confirmation [OK]
Common Mistakes:
  • Confusing readConcern with writeConcern
  • Thinking readConcern controls write confirmations
  • Assuming readConcern affects transaction speed
2. Which of the following is the correct way to specify writeConcern in a MongoDB transaction?
easy
A. { writeConcern: { w: 'majority' } }
B. { readConcern: { w: 'majority' } }
C. { writeConcern: { r: 'majority' } }
D. { writeConcern: 'readConcern' }

Solution

  1. Step 1: Recall writeConcern syntax

    Write concern uses the key w to specify acknowledgement level, e.g., 'majority'.
  2. Step 2: Check options for correctness

    { writeConcern: { w: 'majority' } } correctly uses writeConcern: { w: 'majority' }. Others misuse keys or mix readConcern and writeConcern.
  3. Final Answer:

    { writeConcern: { w: 'majority' } } -> Option A
  4. Quick Check:

    writeConcern uses w key [OK]
Hint: writeConcern uses w, readConcern uses level [OK]
Common Mistakes:
  • Using 'r' instead of 'w' for writeConcern
  • Mixing readConcern and writeConcern keys
  • Passing writeConcern as a string instead of object
3. Given this transaction code snippet, what is the effective read concern level?
const session = client.startSession();
session.startTransaction({ readConcern: { level: 'snapshot' }, writeConcern: { w: 'majority' } });
// transaction operations
await session.commitTransaction();
medium
A. local
B. majority
C. linearizable
D. snapshot

Solution

  1. Step 1: Identify readConcern in transaction options

    The transaction is started with readConcern: { level: 'snapshot' }.
  2. Step 2: Understand readConcern levels

    'snapshot' means the transaction reads a consistent snapshot of data at start time.
  3. Final Answer:

    snapshot -> Option D
  4. Quick Check:

    readConcern level = snapshot [OK]
Hint: Check readConcern.level in startTransaction options [OK]
Common Mistakes:
  • Confusing writeConcern level with readConcern level
  • Assuming default readConcern instead of specified
  • Mixing up 'majority' with readConcern levels
4. Identify the error in this transaction code snippet:
const session = client.startSession();
session.startTransaction({ readConcern: { level: 'majority' }, writeConcern: { w: 1 } });
// transaction operations
await session.commitTransaction();
medium
A. writeConcern w: 1 is invalid
B. Missing session.endSession() call
C. readConcern level 'majority' is invalid
D. startTransaction syntax is incorrect

Solution

  1. Step 1: Check for session lifecycle management

    The code does not call session.endSession() after commitTransaction(). This is necessary to properly release session resources and avoid leaks.
  2. Step 2: Verify other components

    readConcern level 'majority' is valid; writeConcern { w: 1 } is valid (acknowledgement from primary); syntax is correct.
  3. Final Answer:

    Missing session.endSession() call -> Option B
  4. Quick Check:

    endSession after commit/abort [OK]
Hint: Always call session.endSession() after commitTransaction or abortTransaction [OK]
Common Mistakes:
  • Thinking readConcern 'majority' is invalid for transactions
  • Assuming writeConcern w:1 is invalid
  • Believing session.endSession() is optional
5. You want a transaction that reads the most recent confirmed data and ensures all writes are acknowledged by a majority of servers. Which combination of readConcern and writeConcern should you use?
hard
A. readConcern: 'snapshot', writeConcern: { w: 0 }
B. readConcern: 'local', writeConcern: { w: 1 }
C. readConcern: 'majority', writeConcern: { w: 'majority' }
D. readConcern: 'linearizable', writeConcern: { w: 'majority' }

Solution

  1. Step 1: Understand readConcern 'majority'

    This level reads data confirmed by a majority of servers, ensuring recent confirmed data.
  2. Step 2: Understand writeConcern { w: 'majority' }

    This ensures writes are acknowledged by a majority of servers before commit.
  3. Step 3: Evaluate other options

    readConcern: 'local', writeConcern: { w: 1 } uses weaker writeConcern; C uses no write acknowledgement; D uses linearizable readConcern which is stricter than needed.
  4. Final Answer:

    readConcern: 'majority', writeConcern: { w: 'majority' } -> Option C
  5. Quick Check:

    Majority read and write concern = readConcern: 'majority', writeConcern: { w: 'majority' } [OK]
Hint: Use 'majority' for both read and write for confirmed data [OK]
Common Mistakes:
  • Choosing writeConcern w:1 for majority confirmation
  • Confusing 'snapshot' with 'majority' readConcern
  • Ignoring writeConcern w:0 means no acknowledgement
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard