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

Clarify expected behavior for configuring and resetting sessions

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Minor - P4 Minor - P4
    • WT11.0.0, 6.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None

      Summary

      The reconfigure() and reset() functions do not reset the session's configurations. In both of the following examples, the configured "cache_max_wait_ms" is never cleared from the session after it is reset.

      session->reconfigure(session, "cache_max_wait_ms=100");
      session->reset(session);
      
      session->reconfigure(session, "cache_max_wait_ms=100");
      session->reconfigure(session, "");
      session->reset(session);
      

      Motivation

      • Does this affect any team outside of WT? Yes
      • How likely is it that this use case or problem will occur? This seems like an easy mistake to make and the behavior is not defined in the docs from what I can tell.
      • If the problem does occur, what are the consequences and how severe are they? This is a problem for MongoDB because we cache sessions and reuse them, so there is a risk of "poisoning" the session cache and causing future operations to fail in unexpected ways.
      • Is this issue urgent? Not really

      Acceptance Criteria (Definition of Done)

      Documentation update or change in API behavior.

      [Optional] Suggested Solution

      I would prefer that calling reset() clears out any prior cursor configurations, but I also understand why some users might want this behavior. My recommendation would be to update the documentation for reconfigure() and reset() to be more explicit about this behavior.

            Assignee:
            keith.bostic@mongodb.com Keith Bostic (Inactive)
            Reporter:
            louis.williams@mongodb.com Louis Williams
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: