Learning records of mongodb master class (day 19)


Nineteenth days

The chapter to be learned today is 22 transaction development: multi document transaction, which mainly deals with multi document transaction management.


  • Mongodb started to fully support multi document transactions in 4.2
  • The principle of using transactions should be: don’t use them as much as possible.
  • By properly designing the document model, we can avoid the necessity of using most transactions
  • Why? Transaction = lock, node coordination, extra overhead, performance impact

Mongodb acid multi document transaction support

  • Atomicity (atomicity)
    Single form document: supported by 1. X, fields in the document are either updated more or not, and some updates will not appear.
    Replica set, multi table and multi row: supported from 4.0
    Fragment cluster, multi table and multi row: 4.2
  • Consistency
    Writeconcert, readconcert (supported since version 3.2)
  • Isolation
    Readconcert (version 3.2 starts to support)
  • Durability
    Journal and Replication

Isolation level of transaction

  • Before the transaction is completed, changes made to the transaction by operations outside the transaction are not accessible
  • Repeatable read can be achieved if {readconcert: “snapshot”} is used within a transaction

Transaction isolation

That is, changes within a transaction do not affect data outside the transaction before it is committed

db.tx.insertMany([{ x: 1 }, { x: 2 }]);
var session = db.getMongo().startSession();
var coll = session.getDatabase('test').getCollection("tx");
coll.updateOne({x: 1}, {$set: {y: 1}});
Col.findone ({X: 1}); // returns {X: 1, Y: 1}
DB. Tx.findone ({X: 1}); // returns {X: 1}

Repeatable read

Although the data outside the transaction has been updated, the read data is the same before the end of the transaction.

var session = db.getMongo().startSession();
readConcern: {level: "snapshot"},
writeConcern: {w: "majority"}});
var coll = session.getDatabase('test').getCollection("tx");
Col.findone ({X: 1}); // return: {X: 1}
db.tx.updateOne({x: 1}, {$set: {y: 1}});
DB. Tx.findone ({X: 1}); // return: {X: 1, Y: 1}
Col.findone ({X: 1}); // return: {X: 1}

Transaction write mechanism

Mongodb’s transaction error handling mechanism is different from the relational database:

  • When a transaction starts, if the document to be modified by the transaction has been modified outside the transaction, the abort error will be triggered when the transaction modifies the document, because the modification conflicts at this time;
  • In this case, you only need to redo the transaction simply, that is, stop the transaction and restart it;
  • If a transaction has started to modify a document and attempts to modify the same document outside the transaction, the modification outside the transaction will wait for the transaction to complete before proceeding.

Experiment: write conflict

var session = db.getMongo().startSession();
session.startTransaction({ readConcern: {level: "snapshot"},
writeConcern: {w: "majority"}});
var coll = session.getDatabase('test').getCollection("tx");

Continue to use the TX set of the previous experiment, and open two Mongo shells to execute the following statements
Window 1:
Col. updateone ({X: 1}, {$set: {Y: 1}); // normal end
Window 2:
Col. updateone ({X: 1}, {$set: {Y: 2}); // exception - solution: restart the transaction

Experiment: writing conflict (Continued)

Window 1: first transaction, normal commit
coll.updateOne({x: 1}, {$set: {y: 1}});
Window 2: another transaction updates the same data, exception
coll.updateOne({x: 1}, {$set: {y: 2}});
Window 3: update out of transaction, waiting
db.tx.updateOne({x: 1}, {$set: {y: 3}})

Matters needing attention

  • It can implement transaction scenarios similar to relational databases
  • Mongodb 4.2 compatible drivers must be used;
  • By default, the transaction must be completed within 60 seconds (adjustable), otherwise it will be cancelled;
  • The arbitration node cannot be used for transaction fragments;
  • Transactions affect the efficiency of chunk migration. The chunk being migrated may also cause the transaction commit to fail (just retry);
  • The master node must be used to read in multi document transactions;
  • Readconcert should only be set at the transaction level, not on each read-write operation.