Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5323

Design history store concurrent access mechanism

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • Backlog
    • Affects Version/s: None
    • Component/s: None
    • None
    • 13
    • Storage Engines 2019-12-30, Storage Engines 2020-01-13

      In the case of lookaside, we have a pool of five shareable sessions and cursors. A simple lock mechanism is used to provide concurrent access to that pool. Even though certain workloads generated a contention on the lock and the cursors, that approach worked okay for most workloads.

      When the history store replaces lookaside, any application, eviction or checkpoint thread might need access to it. A pool of session/cursor resources protected by a lock is expected to generate an unacceptable amount of contention.

      This ticket is to work on coming up with a new design, to provide access to the history store concurrently without relying on a pool of shared resources.

        1. 20191217_150122.jpg
          4.22 MB
          Sulabh Mahajan
        2. two_txn_per_session.diff
          69 kB
          Sulabh Mahajan

            Assignee:
            sulabh.mahajan@mongodb.com Sulabh Mahajan
            Reporter:
            sulabh.mahajan@mongodb.com Sulabh Mahajan
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: