-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Testing Infrastructure
-
Fully Compatible
-
v4.0
-
Repl 2018-06-04, Repl 2018-06-18, Repl 2018-07-02, Repl 2018-07-16, Repl 2018-07-30, Repl 2018-08-13
We should be able to gain further coverage of transactions when operations are happening on the database concurrently by leveraging the existing FSM workloads.
Unlike the replica_sets_multi_stmt_txn_jscore_passthrough.yml test suite, it will be possible (and in some cases very probable) for operations to trigger a write conflict once run inside of a transaction. robert.guo proposed the idea of retrying a single state function's execution until the transaction commits. In order to make this approach compatible with an arbitrary FSM workload, we'll need to make a copy of the args.data object before the state function is called. This ensures a subsequent execution of the state function when the transaction aborts doesn't (speculatively) contain the effects of the aborted transaction. The args.data object should be reassigned to the possibly mutated value if the transactions commits.
- depends on
-
SERVER-35388 Improve misleading error messages for aggregation stages banned in transactions
- Closed
- is related to
-
SERVER-35964 Delete UBSan concurrency_replication* tasks
- Closed
- related to
-
SERVER-72985 FSM workloads which use the connection cache features should automatically opt-out of using transactions in passthroughs
- Closed