[SERVER-47008] Make the storage API take requests for either checkpoints or journal flushes and move the waitUntilDurable logic above the storage API Created: 20/Mar/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Participants: |
| 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. |