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

Make the storage API take requests for either checkpoints or journal flushes and move the waitUntilDurable logic above the storage API

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Storage
    • None
    • Storage Execution

    Description

      The WiredTigerSessionCache::waitUntilDurable is more complex than it should be and can be made simpler.

      Low down in the WiredTigerSessionCache::waitUntilDurable function, we decide whether to call wt::checkpoint or wt::log_flush based on function parameters or server durability settings.

      Instead, we propose splitting the WiredTigerSessionCache::waitUntilDurable into two functions, one taking checkpoints and the other doing journal flushes, and move the logic deciding which one to call above the storage layer, probably making helper functions.

      It might be a good idea to start the JournalFlusher with startup parameters to tell it which function to call; or maybe just have it call a helper function that decides what to do and call it a day.

      We should see what we can do about moving the JournalListener up a layer(s) while we're about this. The tricky part with the JournalListener is that we need a common place to call it, so all callers update it.

      Attachments

        Activity

          People

            backlog-server-execution Backlog - Storage Execution Team
            dianna.hohensee@mongodb.com Dianna Hohensee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: