Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-35037

Create new concurrency suite that runs consecutive operations inside of a single transaction

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v4.0
    • Sprint:
      Repl 2018-06-04, Repl 2018-06-18, Repl 2018-07-02, Repl 2018-07-16, Repl 2018-07-30, Repl 2018-08-13

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: