Read concern and write concern in transactions in MongoDB - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is read concern in MongoDB transactions?

Read concern determines the level of isolation for reading data in a transaction. It controls how much data must be confirmed as committed before it can be read.

beginner

What does write concern specify in MongoDB transactions?

Write concern defines the level of acknowledgment requested from MongoDB when writing data. It controls how many nodes must confirm the write before it is considered successful.

intermediate

Name two common read concern levels used in MongoDB transactions.

Common read concern levels are local (reads the most recent data on the node) and snapshot (reads a consistent snapshot of data at the start of the transaction).

intermediate

What happens if the write concern level is set too low in a transaction?

If write concern is too low, the transaction might report success before data is fully replicated, risking data loss if a failure occurs.

advanced

How do read concern and write concern work together in MongoDB transactions?

Read concern ensures the transaction reads stable data, while write concern ensures the transaction's writes are safely stored. Together, they balance consistency and durability.

Which read concern level provides a consistent snapshot of data during a transaction?

A snapshot

B majority

C local

D available

The snapshot read concern returns a consistent view of data as it was at the start of the transaction.

What does write concern 'majority' mean in MongoDB transactions?

A Write is acknowledged by the primary only

B Write is not acknowledged

C Write is acknowledged by a majority of replica set members

D Write is acknowledged by all nodes

Write concern 'majority' means the write must be confirmed by most nodes in the replica set before success is reported.

If a transaction uses read concern 'local', what data does it read?

A The most recent data on the node, even if not replicated

B Only committed data from all nodes

C Data from a consistent snapshot

D Data only from the primary node

Read concern 'local' reads the most recent data on the node, regardless of replication status.

Why is setting a high write concern important in transactions?

A To improve read speed

B To allow unacknowledged writes

C To reduce network traffic

D To ensure data durability and reduce risk of loss

A high write concern ensures writes are confirmed by multiple nodes, improving durability and safety.

Which of the following is NOT controlled by read concern in MongoDB transactions?

A Consistency of data read

B Acknowledgment of writes

C Data visibility during reads

D Isolation level of reads

Acknowledgment of writes is controlled by write concern, not read concern.

Explain in your own words what read concern and write concern control in MongoDB transactions.

Think about what you want to guarantee when reading and writing data.

Describe how choosing different read and write concern levels can affect transaction behavior and data safety.

Consider the trade-off between speed and safety.

Practice

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