11-"MongoDB Getting Started Tutorial" MongoDB atomicity and transactions

In MongoDB, the atomicity of the write operation is at the document level, even if the embedded part of the document is modified, the level of the write lock is also document on.

When a write operation is to modify multiple documents, the modification of each document is atomic. The entire write operation is not atomic, and it may be interwoven with other write operations. However, you can use $isolated the isolate operator to limit the write operation so that it is not interwoven with other writes. No isolation performance is higher, but it produces data uncertainty, isolated write operations, and better transactional. MongoDB puts this level entirely under the user's control.

Isolated write operations

MongoDB uses an $isolated operator to isolate a write operation. If a write is to update multiple documents, it can prevent other processes from interleaving with this write operation. Until this write operation is complete, other processes can write.

However, $isolated without a transaction, MongoDB does not roll back the data that has been written if an error occurs during the write process. $isolatednor can it work on a shard cluster.

Characteristics:

• Quarantine does not support shard clusters
• The "all-or-nothing" feature is not supported
• After the MongoDB2.2 version $isolated is replaced$atomic

Class transaction syntax

MongoDB does not support the kind of transactional features in relational databases, and for performance, it gives the programmer the ability to implement this feature. This is what MongoDB officially said two Phase commits two phase commit. While this technique can guarantee the eventual consistency of the data to some extent, the application may read intermediate data in the process of committing or rolling back. For this technique if interested can read the original text.

concurrency control

Concurrency control allows multiple application-tier programs to access the database at the same time without causing data inconsistencies or conflicts.

MongoDB mentions two techniques to solve this problem. The first is the unique index, and the second is called Update if Current .

Use a unique index to prevent multiple processes from repeatedly inserting or updating duplicate values that result.
Update if CurrentThis means that when the data is updated, an expected value is given in the update condition (this value is queried first) to prevent other processes from updating this value before the update. See an example:

var myDocument = db.products.findOne( { sku: "abc123" } );if ( myDocument ) {   var oldQuantity = myDocument.quantity;   var oldReordered = myDocument.reordered;   var results = db.products.update(      {        _id: myDocument._id,        quantity: oldQuantity,        reordered: oldReordered      },      {        $inc: { quantity: 50 },        $set: { reordered: true }      }   )   if ( results.hasWriteError() ) {      print( "unexpected error updating document: " + tojson(results) );   }   else if ( results.nMatched === 0 ) {      print( "No matching document for " +             "{ _id: "+ myDocument._id.toString() +             ", quantity: " + oldQuantity +             ", reordered: " + oldReordered             + " } "      );   }}

Similarly, in the Findandmodify () function:

db.people.findAndModify({    query: { name: "Andy" },    sort: { rating: 1 },    update: { $inc: { score: 1 } },    upsert: true})

If more than one process calls this function at the same time, these processes complete the query phase, and if name there is no unique index on the field, the Upsert phase of the operation may be performed by multiple processes. Causes a duplicate document to be written.

11-"MongoDB Getting Started Tutorial" MongoDB atomicity and transactions