I’m reading the docs about Transactions to make sure I don’t actually let any inconsistencies slip into my production data. Right now, I’m reading the section on Transactions and Read Concern. If I understand it correctly, the read concern defaults to “local” if I don’t set anything explicitly.
What implications does this “local” read concern have for the transaction and consistency of my data? What I want to know specifically is if there are circumstances where a transaction could lead to partial updates or inconsistent data even though all the involved database operations are part of the same transaction/session. I imagine this could be caused because I am reading data that has actually been rolled back and execute my transactions with this wrong data.
Are my worries here justified or do I understand the read concern wrong?
What I want to know specifically is if there are circumstances where a transaction could lead to partial updates or inconsistent data even though all the involved database operations are part of the same transaction/session . I imagine this could be caused because I am reading data that has actually been rolled back and execute my transactions with this wrong data.
Read concern is all about replica set, "local" and roll back refers to concepts in that area, not in transactions.
MongoDB transaction follows the ACID property so partial uncommitted writes and inconsistent data should not be visible outside of that uncommitted transaction.
Please also refer to the following documentation which may be useful:
Can anyone help me? Maybe someone from the staff? This is important for my production database.
The community forum users will try help as best as they can but please note that there is no SLA for responses. If it is urgent and/or affecting production heavily it may be better to subscribe to a support plan and create a support case which has dedicated SLAs (I have linked this to Cloud support as opposed to on-prem support as I believe you are utilising Atlas based off previous posts but please let me know if otherwise).
Thank you for your response. I wrote the second comment to avoid that the thread automatically gets closed.
You said that the read concern is not related to transactions, then why does the documentation specifically talk about “Transactions and Read Concern”?
What I want to know specifically is if there are circumstances where a transaction could lead to partial updates or inconsistent data
Outside of the transaction, you will not see an inconsistent state of the database as the transaction is done in an “all-or-nothing” manner.
then why does the documentation specifically talk about “Transactions and Read Concern”?
The Session.startTransaction() documentation contains further details specifically regarding readConcern:
Optional. A document that specifies the read concern for all operations in the transaction, overriding operation-specific read concern.
In addition to the above, the same page also describes atomicity with regards to transactions, perhaps more specific to your example:
When a transaction commits, all data changes made in the transaction are saved and visible outside the transaction. That is, a transaction will not commit some of its changes while rolling back others.
Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.
In short, the options discussed changes how individual statements behave within the transaction. They do not affect statements outside the transaction. Due to the ACID guarantees of the transaction, statements outside the transaction would never see the database in an inconsistent state, no matter what read concern you’re using.
However if you’re using the find() statement inside the transaction and the rest of your transaction makes decision based on the result of that find(), you might want to take a look at the blog post How To SELECT ... FOR UPDATE inside MongoDB Transactions | MongoDB Blog to see if this answers your concerns.