Read concern and write concern in transactions in MongoDB - Mini Project: Build & Apply

Using Read Concern and Write Concern in MongoDB Transactions

📖 Scenario: You are managing a small online bookstore database using MongoDB. You want to ensure that when you update book stock and sales records together, the data stays consistent and reliable. To do this, you will use transactions with specific read and write concerns.

🎯 Goal: Build a MongoDB transaction that updates the stock and sales collections with readConcern set to majority and writeConcern set to { w: 'majority' }. This ensures your transaction reads the most committed data and writes are acknowledged by the majority of nodes.

📋 What You'll Learn

Create a session to start a transaction

Set the transaction's read concern to 'majority'

Set the transaction's write concern to { w: 'majority' }

Update the 'stock' collection inside the transaction

Update the 'sales' collection inside the transaction

Commit the transaction

💡 Why This Matters

🌍 Real World

Transactions with read and write concerns are used in real-world applications to keep data consistent and reliable, especially in financial or inventory systems.

💼 Career

Understanding how to use transactions with read and write concerns is important for database administrators and backend developers working with MongoDB to ensure data integrity.

1

Setup MongoDB collections and start a client session

Create a MongoDB client connection called client. Then get the database bookstore and collections stock and sales. Finally, start a client session called session.

MongoDB

const { MongoClient } = require('mongodb');

// Your code here

Hint

Use new MongoClient('mongodb://localhost:27017') to connect. Use client.db('bookstore') to get the database. Use db.collection('stock') and db.collection('sales') to get collections. Use client.startSession() to start a session.

2

Configure transaction options with read and write concerns

Create a variable called transactionOptions that sets readConcern to { level: 'majority' } and writeConcern to { w: 'majority' }.

MongoDB

const { MongoClient } = require('mongodb');

const client = new MongoClient('mongodb://localhost:27017');

await client.connect();

const db = client.db('bookstore');
const stock = db.collection('stock');
const sales = db.collection('sales');

const session = client.startSession();

// Your code here

Hint

Define transactionOptions as an object with readConcern and writeConcern properties set to the specified values.

3

Start the transaction and update collections inside it

Use session.startTransaction(transactionOptions) to start the transaction. Then update the stock collection to decrease quantity by 1 for the book with title 'MongoDB Basics'. Next, update the sales collection to increase count by 1 for the same book. Use session in both update operations.

MongoDB

const { MongoClient } = require('mongodb');

const client = new MongoClient('mongodb://localhost:27017');

await client.connect();

const db = client.db('bookstore');
const stock = db.collection('stock');
const sales = db.collection('sales');

const session = client.startSession();

const transactionOptions = {
  readConcern: { level: 'majority' },
  writeConcern: { w: 'majority' }
};

// Your code here

Hint

Call session.startTransaction(transactionOptions). Use updateOne on stock and sales with the filter { title: 'MongoDB Basics' } and the update operators { $inc: { quantity: -1 } } and { $inc: { count: 1 } } respectively. Pass { session } as options.

4

Commit the transaction and end the session

Commit the transaction using session.commitTransaction(). Then end the session with session.endSession().

MongoDB

const { MongoClient } = require('mongodb');

const client = new MongoClient('mongodb://localhost:27017');

await client.connect();

const db = client.db('bookstore');
const stock = db.collection('stock');
const sales = db.collection('sales');

const session = client.startSession();

const transactionOptions = {
  readConcern: { level: 'majority' },
  writeConcern: { w: 'majority' }
};

await session.startTransaction(transactionOptions);

await stock.updateOne(
  { title: 'MongoDB Basics' },
  { $inc: { quantity: -1 } },
  { session }
);

await sales.updateOne(
  { title: 'MongoDB Basics' },
  { $inc: { count: 1 } },
  { session }
);

// Your code here

Hint

Call await session.commitTransaction() to save changes. Then call session.endSession() to finish.

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