Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2860

Introduce new API for starting a causally consistent session from the timestamps of another operation or client session

    • Type: Icon: New Feature New Feature
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Component/s: Causal Consistency
    • Needed
    • Hide

      Summary of necessary driver changes

      •  

      Commits for syncing spec/prose tests
      (and/or refer to an existing language POC if needed)

      •  

      Context for other referenced/linked tickets

      •  
      Show
      Summary of necessary driver changes   Commits for syncing spec/prose tests (and/or refer to an existing language POC if needed)   Context for other referenced/linked tickets  

      Summary

      The goal is to make using causal consistency across multiple client sessions less surprising to get correct.

      Motivation

      Who is the affected end user?

      Application developers who want to make use of the MongoDB Server's stronger consistency guarantees have a challenging time writing highly-concurrent applications correctly.

      How does this affect the end user?

      They get confused.

      How likely is it that this problem or use case will occur?

      Unclear how often this is a problem though Max has been called on to help in three (3) separate instances. All instances were with the Golang driver but the syntax is generally the same across drivers.

      If the problem does occur, what are the consequences and how severe are they?

      Operations attempted on the MongoDB Server fail with an error message.

      readConcern afterClusterTime value must not be greater than the current clusterTime
      

      This error is typically a sign the application was written by calling advanceOperationTime() or using afterClusterTime as a read concern option directly without also calling advanceClusterTime() explicitly.

      Is this issue urgent?

      Causal consistency was introduced in MongoDB 3.6 and the client session API has not been substantially changed since then. More recently there are internal teams which are using causal consistency to solve limitations (e.g. SERVER-53813 and reading from the primary, or safely reading from nearest member / secondaries) and so any urgency would come from a perceived increase usage if there's any urgency at all.

      Is this ticket required by a downstream team?

      Both App Services and Mongosync would benefit from changes to the Golang driver.

      Is this ticket only for tests?

      This ticket has functional impact.

      Acceptance Criteria

      It must be possible in a single function call on each client session to run an operation in client session B causally after an operation in client session A. For client sessions from the same MongoClient, this is already possible with the existing client session API:

      session_a = client.start_session()
      session_b = client.start_session()
      session_b.advance_operation_time(session_a.operation_time)
      # No need to do session_b.advance_cluster_time(session_a.cluster_time) because the MongoClient
      # already gossips the highest $clusterTime seen across all client sessions.
      

      However the same automatic highest $clusterTime gossiping is not also true for client sessions from different MongoClients. Both App Services and Mongosync use multiple MongoClients which connect to the same MongoDB Cluster within the same process.

            Assignee:
            rishabh.bisht@mongodb.com Rishabh Bisht
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: