How do 'Read Concern' and 'Write Concern' settings affect a transaction's behavior?

Question

Accepted Answer

In MongoDB, multi-document transactions allow you to set Read Concern and Write Concern at the transaction level, which overrides any client, database, or collection-level defaults for the duration of the transaction. Crucially, these concerns cannot be set on individual operations within the transaction—they must be configured at the transaction level or inherited from the session . These settings determine the transaction's isolation guarantees and persistence behavior. // Example: Starting a transaction with specific concerns
const session = client.startSession();

const transactionOptions = {
  readConcern: { level: 'snapshot' },
  writeConcern: { w: 'majority', j: true },
  readPreference: 'primary'
};

session.startTransaction(transactionOptions);

try {
  // Operations within the transaction automatically use these concerns
  const accounts = client.db('bank').collection('accounts');
  const transactions = client.db('bank').collection('transactions');
  
  await accounts.updateOne(
    { _id: 1 },
    { $inc: { balance: -100 } },
    { session }
  );
  
  await transactions.insertOne(
    { from: 1, amount: 100, timestamp: new Date() },
    { session }
  );
  
  await session.commitTransaction();
} catch (error) {
  await session.abortTransaction();
} finally {
  session.endSession();
} Snapshot level: Provides a consistent snapshot of data as of the transaction start time, preventing phantom reads across multiple documents  Majority level: Returns data that has been committed to a majority of nodes, ensuring reads reflect durable writes  Local level: Returns the most recent data from the node, but without guarantee of majority commitment  The chosen read concern level directly impacts the transaction's isolation guarantees and which data modifications are visible during the transaction  Majority write concern: Ensures the transaction's writes are acknowledged by a majority of voting nodes before commit returns success, providing strong durability guarantees  w:1: Acknowledges writes after the primary node applies them, offering lower latency but with the risk of rollback if the primary fails before replication  Journal option (j: true): Forces acknowledgment that writes are persisted to the on-disk journal on each node specified by the w value  wtimeout: Prevents indefinite blocking by setting a time limit for achieving the requested write concern; after timeout, the operation fails without rolling back successful writes  The combination of these settings determines the overall ACID properties of your transaction. For example, using `snapshot` read concern with `majority` write concern provides the highest level of consistency and durability, but with higher latency . The concerns are applied hierarchically: transaction-level settings override client and database defaults, and individual operations within the transaction cannot specify different concerns—they inherit the transaction settings .

How do 'Read Concern' and 'Write Concern' settings affect a transaction's behavior?

Read Concern and Write Concern in a transaction control the data consistency level of reads and the durability acknowledgment level of writes, respectively, and are set at the transaction level, not on individual operations.

Scenario Questions

Follow-up Questions