The wording in the manual regarding Production Considerations
for transactions (Node.js) is unclear to me regarding whether it applies to both replicaSets and sharded clusters.
Outside Reads During Commit
During the commit for a transaction, outside read operations may try to read the same documents that will be modified by the transaction. If the transaction writes to multiple shards, then during the commit attempt across the shards
Outside reads that use read concern "snapshot" or "linearizable", or are part of causally consistent sessions (i.e. include afterClusterTime) wait for all writes of a transaction to be visible.
Outside reads using other read concerns do not wait for all writes of a transaction to be visible but instead read the before-transaction version of the documents available.
From the above, it is not clear to me whether this also applies to replicaSets, or only to sharded clusters. This paragraph is repeated identically on the page Production Considerations (Sharded Clusters), which further leads me to suspect that it only applies to sharded clusters (and not replica sets).
I would really appreciate clarification on this issue, if anyone is able to provide it!
Indeed, it could be challenging to interpret the words without any specifics. The paragraph that you quoted is a consideration for sharded clusters, as it would likely to affect sharded cluster than replica sets and may be an unwanted behaviour depending on use cases.
Let’s use MongoDB version 5.0 (current) behaviour as an example:
A client application performs a transactions to write multiple documents into the database. The transaction utilises write-concern"majority" (default)
In a sharded cluster, if the write operation goes to more than one shard in the transaction, an outside read operation that utilises read concern "local" (default) may not wait for the results of the committed transaction to be visible across all shards. i.e. if the transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, the outside read may read the results of write 1 without seeing write 2.
This would be suitable for an eventual-consistency data type which focuses on speed.
However, if the outside read operation utilises read concern "linearizable" it would wait for all of the writes to be visible.
This would be suistable for a strong-consistency data type which focuses on correctness.
Different read concerns should be configured appropriately depending on the use case.
While in a replica set with three members and no arbiters, an outside read operation (on primary) that utilises read concern "local" or "linearizable" would see similar results in the example case above.