So MongoDB 4.0 comes with multi document transactions. My question is, does this enable the same functionality you get with SQL Procedures?
The use case would be
Common db drivers will usually just stack up any commands you issue until you call commit and then run them all after another on the db's machine. So any read I run in my server code are run before the transaction is actually commited and therefore other connections could alter data in between read and write operations.
Will MongoDB 4.0 cover this functionality?
MongoDB added support for multi-document ACID transactions in version 4.0 in 2018 and extended that support for distributed multi-document ACID transactions in version 4.2 in 2019. MongoDB's document model allows related data to be stored together in a single document.
For situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports multi-document transactions. With distributed transactions, transactions can be used across multiple operations, collections, databases, documents, and shards.
Yes, you can have ACID with NoSQL! Not having it means that the system didn't consider the 'Management System' part of the DBMS in its original design.
Does MongoDB support ACID transaction management and locking functionalities? No. MongoDB does not support default multi-document ACID transactions. However, MongoDB provides atomic operation on a single document.
Will MongoDB 4.0 cover this functionality?
The short answer is yes for atomicity.
In MongoDB, Transactions (also called multi-documents transactions) are associated with a session. That is, you start a transaction for a session. At any given time, you can have at most one open transaction for a session.
You can not lock the entire collection for writes. You may want to create multiple transactions to ensure that writes are not interlacing/overriding between your processes. MongoDB uses Optimistic Locking instead of Pessimistic Locking.
So any read I run in my server code are run before the transaction is actually commited and therefore other connections could alter data in between read and write operations
Similarly in MongoDB multi-document transactions. For example, using mongo shell:
s1 = Mongo().startSession()
sessionTest = s1.getDatabase("databaseName").test;
s1.startTransaction()
sessionTest.find({a:"foo"})
> {_id: ObjectId(..), a:"foo", b:1}
// Let's update the record outside of the session (i.e. another process)
db.test.update({a:"foo"}, {$set:{b:2}})
sessionTest.update({a:"foo"}, {$set:{b:9}})
// You'll get a WriteConflict error because the the document has been modified outside of the session.
Also note that while the transaction is open, no data changes made by operations in the transaction is visible outside of the transaction.
See also Atomicity Example.
Worth noting that MongoDB is a distributed database, so you also need to be aware of the different options for consistency. You can specify these options when initiating Session.startTransaction() depending on the use case :
Read Isolation (Read Concern): MongoDB multi-document transactions support read concern "snapshot", "local", and "majority".
Write Acknowledgement (Write Concern).
Multi-document transactions support read preference primary and all operations in a given transaction must route to the same member.
You may also be interested in Engineering Chalk and Talks: MongoDB Transactions videos which contain some technical explanations behind MongoDB transactions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With