From MongoDB 4.0 onwards, we now support Replica Set transactions.
Before I go into lots of detail about the transactions, be advise that the Write Concern mechanism is orthogonal to the Transactions support.
This means that the way that a WriteConcern is enforced / guaranteed / applied, is independent of how transactions are applied.
That said, when combining transactions + writeConcerns the expectations should be clarified.
Transactions are all or nothing ACID operations, this means that a combined set of operations can be aborted (rolled-back) or committed.
Transactions will be prone to conflicts, and there is a conflict resolution mechanism, which is exposed to the client application, that will drive you to make decisions, based on what the conflict is about:
All write operations of a transaction, until an abort or commit, are bound to the Primary node. This means that within the set of operations of a transaction, until an abort or commit, all write operations occur within the primary.
You can initiate a transaction asking for
w: majority, but that will only take place once the transaction gets committed, and not to the individual set of operations in transaction, but to all write operations of that same transaction.
If (for ex
w:majority) write concern defined for a transaction does not get satisfied, the same set of expectations will be meet, in the sense the the current primary will acknowledge the writes, potentially several, and that the number secondaries of secondary nodes required to confirm the WriteConcern was not meet within the defined
wtimeout. Nevertheless, the data has been confirmed and committed in the Primary node.
Now, WriteConcern in isolation, without considering ReadConcerns may not be enough to ensure full data availability. The fact that we write to a majority of nodes, ensures that the data we’ve provided, and in a Transaction committed, reached all the designated nodes. However, if we want to guarantee that all the data that write, in a distributed system like MongoDB, we also need to ensure that before writing that same data, we are reading with
ReadConcern.Snapshot in a transaction, to avoid any potential stale read.
Don’t forget, there is a tradeoff between always reading and writing from/to a majority of nodes, your operations will take longer to complete and acknowledge.
Within the transactions, while write concerns are pretty straightforward, the readConcerns are a bit more elaborate, in the set of conflicts and resolution mechanism that might take place.
We will soon be adding Transactions module to the M220 courses, where we hope to clarify even more how these work together.