Read concern and write concern in transactions in MongoDB - Step-by-Step Execution

Concept Flow - Read concern and write concern in transactions

Start Transaction

↓

Set Read Concern

↓

Read Data

↓

Set Write Concern

↓

Write Data

↓

Commit Transaction

↓

End Transaction

This flow shows how a transaction sets read and write concerns before reading and writing data, then commits to ensure data consistency.

Execution Sample

MongoDB

session.startTransaction({readConcern: {level: 'snapshot'}, writeConcern: {w: 'majority'}});
const doc = collection.findOne({}, {session});
collection.insertOne({name: 'Alice'}, {session});
await session.commitTransaction();

Starts a transaction with snapshot read concern and majority write concern, reads a document, inserts a new one, then commits.

Execution Table

Step	Action	Read Concern	Write Concern	Result
1	Start transaction	snapshot	majority	Transaction started with specified concerns
2	Read document	snapshot	majority	Reads data consistent with snapshot
3	Insert document	snapshot	majority	Document staged for write
4	Commit transaction	snapshot	majority	Writes applied and committed
5	End transaction	N/A	N/A	Transaction ends, session ready for next

💡 Transaction ends after commit; read and write concerns ensure data consistency and durability.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
readConcern	none	snapshot	snapshot	snapshot	snapshot	N/A
writeConcern	none	majority	majority	majority	majority	N/A
transactionState	none	started	reading	writing	committing	ended
dataRead	none	none	document data	document data	document data	document data
dataWritten	none	none	none	new document staged	new document committed	new document committed

Key Moments - 3 Insights

Why do we set readConcern before reading data in a transaction?

Read concern defines the consistency level of data read. Setting it before reading ensures the transaction sees a stable snapshot of data, as shown in step 2 of the execution table.

What happens if writeConcern is not set in a transaction?

Without write concern, writes may not be guaranteed durable or replicated. Setting writeConcern before writes (step 3) ensures data is safely written and replicated before commit (step 4).

Why must commitTransaction happen after setting concerns and performing operations?

Commit applies all staged writes atomically. It uses the set writeConcern to ensure durability. This final step (step 4) confirms all changes are saved consistently.

Visual Quiz - 3 Questions

Look at the execution table, what is the readConcern level during the data read step?

A majority

B snapshot

C local

D none

💡 Hint

Check the 'Read Concern' column at step 2 in the execution table.

At which step does the transaction apply the writes to the database?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look at the 'Result' column for when writes are committed in the execution table.

If writeConcern was set to 'w:1' instead of 'majority', how would the write durability change?

A Writes would not be acknowledged at all

B Writes would be more durable, acknowledged by all nodes

C Writes would be less durable, acknowledged by only one node

D Writes would fail immediately

💡 Hint

Refer to the meaning of writeConcern values in the variable_tracker and key moments.

Concept Snapshot

Transactions in MongoDB use readConcern to control data consistency during reads
and writeConcern to ensure durability of writes.
Set readConcern before reading data to get a stable snapshot.
Set writeConcern before writes to guarantee replication.
Commit applies all writes atomically with the specified concerns.

Full Transcript

This visual execution trace shows how MongoDB transactions use readConcern and writeConcern. The transaction starts with readConcern set to 'snapshot' and writeConcern set to 'majority'. This means reads see a consistent snapshot of data, and writes are replicated to a majority of nodes before commit. The transaction reads a document, stages a new document for insertion, then commits. The commit applies all writes atomically with the specified durability. Variables like readConcern and writeConcern remain constant during the transaction. Key moments include why readConcern is set before reading, why writeConcern ensures durability, and why commit applies all changes. The quizzes test understanding of these steps and their effects on data consistency and durability.

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