Refactor the Recoverable Critical Section API from ShardingRecoveryService

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • None
    • 3
    • TBD
    • 🟦 Shard Catalog
    • None
    • None
    • None
    • None
    • None
    • None

      The ShardingRecoveryService is a decoration on the service context that manages the recoverable critical section. It enters the critical section via the appropriate in-memory component (e.g., DSS, CSS) and ensures the state is replicated with majority write concern by writing to a special collection. It also keeps the in-memory sharding components in sync with their on-disk counterparts during events like rollbacks or startup (e.g., handling the critical section, DSS, etc.).

      While it makes sense for ShardingRecoveryService to exist to synchronize in-memory and on-disk sharding components, placing the API for entering and exiting the critical section in this service can be misleading - we are giving more than one responsibility to this class. These operations (enter/exit critical section) do not share any state or variables with the service itself and should instead be implemented as (e.g.) free functions.

      Additionally, the current method naming does not follow standard conventions for critical sections and lacks consistency with in-memory representation methods (e.g., ShardingRecoveryService::acquireRecoverableCriticalSectionBlockWrites vs. ShardingMigrationCriticalSection::enterCriticalSectionCatchUpPhase).

            Assignee:
            Unassigned
            Reporter:
            Pol Pinol
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: