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.