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

Repeated reads concurrency workloads should reset prevDocuments when entire transaction is retried

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.7
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Sharding 2018-12-17
    • 28

      The concurrency workloads multi_statement_transaction_atomicity_isolation_repeated_reads.js and multi_statement_transaction_simple_repeated_reads.js start transactions with snapshot read concern and run several repeated collection scans, asserting the same documents are returned by each query. They do so by saving the results of each scan to a variable prevDocuments (initially undefined) and asserting if prevDocuments has been set that it equals the most recent result.

      The problem is that prevDocuments is defined outside of the transaction retry loop, so if a transaction aborts with a TransientTransactionError and is retried with a higher txnNumber, prevDocuments will not be overwritten and may contain the results from a read in an earlier transaction, which the new transaction is not guaranteed to also return (since the test is concurrently modifying documents in the collection). Instead, prevDocuments should be reset within the transaction retry loop to prevent this.

            Assignee:
            jack.mulrow@mongodb.com Jack Mulrow
            Reporter:
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: