-
Type: Task
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
Sharding 2019-01-28, Sharding 2019-02-11, Sharding 2019-02-25
We require that config.transactions and TransactionParticipant have consistent state after every command (or the session is invalidated) so that subsequent users of TransactionParticipant know whether the session needs to be reloaded from disk. We will always update config.transactions before updating the in-memory state in TransactionParticipant. If we throw an exception before updating the in-memory state, we must invalidate the session. Audit all abort, commit, and prepare codepaths to ensure they follow this pattern
- is related to
-
SERVER-40051 Make committingWithoutPrepare state uninterruptible
- Closed
-
SERVER-38135 Do not allow transactions on shard servers when the featureCompatibilityVersion is 4.0
- Closed
- related to
-
SERVER-38132 Aborting a transaction must always update config.transactions and write an abort oplog entry
- Closed
-
SERVER-38133 When asked to continue a transaction whose txnNumber is too new, TransactionParticipant must abort that transaction
- Closed