In the middle of February 2018 during the Chinese spring festival holiday, we received the following news from the MongoDB community:
“MongoDB 4.0 will add support for multi-document transactions, making it the only database to combine the speed, flexibility, and power of the document model with ACID guarantees.”
We know that ACID is a very basic feature in the traditional DBMS and it should be a selling point for many DBMS products. However, MongoDB is a document based NoSQL system, which provides many fancy functionalities such as a flexible schema and data model (you don’t need a static model to write to MongoDB), powerful aggregation and analytics etc. It does not support a transaction commit and rollback like what we did in the traditional SQL statement. This is being changed in the NoSQL world.
What is ACID?
The term of ACID represents 4 keywords:
- Atomicity. This property requires that each transaction should be “all success or all failed”: if one part of the transaction fails, then the entire transaction fails and the database state is left unchanged.
In the current version of MongoDB, its atomicity is applied to a document-wide transaction, but not across multiple documents. In most use cases, we can say it is atomic. But in other complex cases, without transactions, a developer would have to implement custom logic in the application layer.
- Consistency. This property requires that any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination of those.
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
In the replica set mode, there are primary Mongo servers and secondary servers. It has been fulfilled to ensure the consistency in a single node or across nodes applying to a single document. But if you write to multiple documents and some of them fail, you have to handle it in your application code.
- Isolation. This property is for concurrent executions. It requires that if transactions are executed concurrently, the result is equivalent to their serial execution. A transaction cannot see the partial result of the application of another one.
This manual can explain the MongoDB isolation property in detail.
- Durability. This ensures that once a transaction has been committed, it will remain so, even in the event of power loss, crash, or errors.
In the earlier version, it didn’t support for durability much, but it was getting quite better. This blog from MongoDB site has explained it well.
What Will MongoDB Bring in Version 4.0?
We have been using MongoDB in several projects and teams, which is good news for developers. With MongoDB transactions, we can eliminate the complex logic in applications and leave it to the MongoDB server to handle. It is currently set for release this summer. The following diagram shows each big change and evolution to expect from MongoDB. We can focus on the yellow items, which are currently being developed. In MongoDB 4.0*, the transactions will work across a single replica set, and MongoDB 4.2* will support transactions across a sharded deployment.
Source from: https://www.mongodb.com/blog/post/multi-document-transactions
Hence, once this is released, developers can be more focused on other high-value work instead of spending lots of time handling multiple documents and exceptions. The application Java code will be as simple as seen below:
