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

FSM workloads which use the connection cache features should automatically opt-out of using transactions in passthroughs

    • Fully Compatible
    • Sharding NYC 2023-01-23

      concurrency*.yml test suite which set TestData.runInsideTransaction = true use withTxnAndAutoRetry() to start and automatically retry a transaction until it commits. This allows operations run by a $config.states function to implicitly be performed inside a transaction without changing the FSM workload itself.

      Some FSM workloads enable the connection cache to allow reading from a secondary member of a replica set or shards and config servers in a sharded cluster. The changes from SERVER-19630 additionally made it so the operations on these other nodes in the cluster use the same underlying DriverSession object. This was motivated by wanting to ensuring causal consistency when reading from other members. However, using the same underlying DriverSession object also means the FSM workload is able to start a transaction on the config server replica set which won't automatically be committed by the withTxnAndAutoRetry() because the withTxnAndAutoRetry() function receive a DriverSession associated with a mongos connection object. And because the testing-default transaction lifetime limit is 24 hours, an FSM workload which leaks a transaction on a shard or config server will cause a timeout in Evergreen.

      We should instead have any $config.states function which makes use the connection cache automatically opt-out of runnings its operations within a transaction. This sacrifices a small amount of test coverage for little effort because usage of the connection cache is uncommon in FSM workloads. (A more complete solution might be to opt-out of using transactions only for operations using connections from the connection cache. But this would require revisiting how to provide causal consistency when using the connection cache without also sharing the transaction state of the DriverSession.)

            Assignee:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: