Multi-Document ACID Transactions

MongoDB has supported multi-document atomicity, consistency, isolation, and durability (ACID) transactions since the release of MongoDB 4.0 in 2018. Transactions are logical groups of processes, with each group containing several reads or writes across different documents. Although single-document operations in MongoDB already offer basic transactional features that meet the data integrity needs of most applications, the addition of multi-document ACID transactions provides you with increased flexibility.

This chapter will cover the following topics:

• Significance and properties of transactions
• Fundamentals and implementation steps for multi-document ACID transactions
• Best practices and limitations for multi-document ACID transactions

Why are transactions useful?

Before examining how MongoDB treats transactions and its technical requirements, let's examine what transactions are, when they're needed, and the benefits and constraints they bring to your applications.

Formally, transactions are logical units of work. Every transaction is self-contained and defined; performed within a database management system against a database, and generally composed of multiple databases read and/or write operations.

From a practical standpoint, a transaction can be viewed as a sequence of database operations, considered complete only when every operation within the transaction has been executed successfully.

There are numerous situations in which your databases may need to perform read and write operations to and from multiple documents. These documents may reside in the same collection, or they may belong to different collections. These operations often have the constraint that they should all either succeed...

ACID properties

ACID is widely accepted as a framework that a transaction must meet to be defined as a proper or true transaction. These properties ensure database transactions are reliable and consistent, serving as the criteria for a unit of work to be considered a transaction:

• Atomicity implies that all the operations in a transaction are either performed successfully or not at all, meaning that if one operation in a transaction fails, the entire transaction is rolled back.
• Consistency ensures that all the data in a database is consistent with the results of the transaction.
• Isolation prevents transactions from interfering with each other. The implication of this property is that two transactions will not see each other's changes until both transactions have been committed.
• Durability ensures that once a transaction is committed, the changes are permanent. In this way, changes are not lost even if the database crashes.

Let's look at these concepts...

MongoDB implementation of ACID

MongoDB ensures atomicity for single-document operations, and this is enough for most real-world cases. However, sectors such as finance and fintech, with stringent requirements, demand different treatment in MongoDB. In the case of financial and banking sectors, applications often handle huge numbers of accounts and financial transactions, all of which need verification. These transactions often span multiple documents—thousands or more.

Generally, multi-document ACID transactions are used when an unbounded number of entities that cannot fit into an array of subdocuments as the main document, outgrow the maximum BSON document size (16MB, currently supported by MongoDB). If you're experienced in relational database management systems (RDBMS), you will find MongoDB's multi-document semantics very familiar and straightforward.

According to a MongoDB seminal white paper on ACID transactions (https://www.mongodb.com/collateral/mongodb...

Best practices

There are several best practices to help make your work with transactions simpler. This section will give a brief overview of these practices.

Generally, you can avoid multi-document ACID transactions by using rich document models through a careful process of data modeling. The modeling phase can help you avoid using transactions altogether, and in many cases, this is always something to keep in mind. However, if your application requires the use of transactions, they integrate seamlessly into your non-transactional workflow, but should be subject to some particular considerations.

As stated previously, transactions have a default maximum time limit set to 60 seconds. This value can be increased by modifying the transactionLifetimeLimitSeconds server parameter at the mongod level. If you're working with a sharded cluster, this parameter must be set on all shard replica members. After this period has expired, as you've seen in the example, the transaction...

Summary

This chapter explored ACID-compliant multi-document transactions in MongoDB. You learnt the principles of the ACID transaction paradigm. Further, you saw how MongoDB handles these requirements, including the strictest requirements, which are sometimes unavoidable. You also learned when to use transactions, when it's best to avoid them, how to use them, their best practices, their limitations, and how to mitigate them.

You followed a simple yet illustrative transaction example, and tested a transaction from the MongoDB Shell. You explored the transaction behavior from within, and observed how it looks like from outside the transaction. You also saw how a transaction is committed, and how to handle failure conditions that require the transaction to be aborted.

The next chapter will address key facets of the MongoDB document model, encompassing indexing, index optimization, and its impact on your overall system.