[DRIVERS-2077] Driver sessions should not require server selection on `startSession` Created: 06/Dec/17  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: Sessions
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Matt Broadstone Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Driver Changes: Needed

 Description   

TLDR: "startSession MAY report an error if sessions are not supported by the deployment (see How to Check Whether a Deployment Supports Sessions)."

The drive sessions spec currently indicates that

startSession MUST report an error if sessions are not supported by the deployment (see How to Check Whether a Deployment Supports Sessions).

I think this language constricts design, and should be loosened to a MAY. Generally, all startSession does is creates a local session id (it used to be a command, which could justify the requirement), it does not do any I/O and therefore I think we should be able to defer the potential server selection to the time of operation execution.

For async drivers (such as node) the current prose would require that the method be asynchronous, turning this code:

MongoClient.connect('mongodb://localhost/test').then(client => {
  const session = client.startSession({ causalConsistency: true });
  const coll = client.db('foo').collection('bar');
 
  return coll.insert({ a: 42 }, { session: session })
});

into:

MongoClient.connect('mongodb://localhost/test').then(client => {
  client.startSession({ causalConsistency: true }).then(session => {
    const coll = client.db('foo').collection('bar');
    return coll.insert({ a: 42 }, { session: session });
  });
});

While this is purely a cosmetic complaint at this point, I think the deeper level here is the concern about locality of the session support check. Driver sessions also require that implicit sessions be created for all operations where an explicit session has not been provided. This means that the check for topology sessions support must also happen in the implicit case. If we defer the check in startSession to the point of operation execution, we can use the same path to determine session support for both explicit and implicit cases.



 Comments   
Comment by Matt Broadstone [ 19/Mar/18 ]

rathi.gnanasekaran this isn't required for 4.0

Comment by Robert Stam [ 08/Dec/17 ]

I never said we should not be concerned about checking whether sessions unexpectedly became unsupported after startSession was called. I just said that wasn't likely to happen very often.

Comment by Matt Broadstone [ 08/Dec/17 ]

rstam I'm unclear as to where we are drawing the line on "unlikely to happen" here. As far as I can tell, connecting to a topology that doesn't support sessions, when your intention is to use sessions, is probably pretty unlikely in the first place. If we are really this concerned about failing when we send the startSession command to a topology that doesn't support them, then I would argue we MUST be equally concerned about sending later commands to a deployment which has changed and may now potentially not support them.

Comment by A. Jesse Jiryu Davis [ 07/Dec/17 ]

The C Driver follows the "How to Check Whether a Deployment Supports Sessions" instructions:

If the TopologyDescription and connection type indicate that the driver is not connected to any servers, OR is not a direct connection AND is not connected to a data-bearing server, then a driver must do a server selection for any server whose type is data-bearing. Server selection will either time out or result in a TopologyDescription that includes at least one connected, data-bearing server.

So if the C Driver's topology has no known servers, it runs server discovery, then checks if sessions are supported.

The mongoc_client_session_t's operation time and cluster time are zero until the session is used, then they're updated. This is also per spec I think.

Anyway, I support Matt's request to relax this. If it's really inconvenient in Node to make users treat startSession as an async function, then it's ok if the check is deferred until the first operation with the session begins.

Comment by Robert Stam [ 07/Dec/17 ]

We should make a distinction between explicit sessions and implicit sessions.

I am saying that when an application calls startSession to explicitly create a session it should receive an error back if sessions are not supported. It doesn't make sense for startSession to silently succeed and for subsequent operations against that session to fail at a later time.

For implicit sessions, a driver could create an implicit session without knowing whether sessions are supported or not, but there is not really any advantage to doing so.

Regarding the scenario where sessions were supported at the time startSession was called but somehow no longer supported by the time an operation is performed using that session, that is unfortunately true and something drivers MUST check for. It is also exceedingly rare in practice and therefore not really a good excuse for not checking whether sessions are supported at the time startSession is called explicitly by an application.

Comment by Matt Broadstone [ 07/Dec/17 ]

I disagree. It is only really important to know if a topology supports sessions when you are about to send sessions to said topology. startSession only creates a local session id (this could be a dummy or one thats actually used). At very least, the topology might have changed between startSession and actually sending the command with lsid, so you will also have to check at the time of operation execution (as you currently have to do with implicit sessions).

I'm not convinced it gives me any more useful information to check for this support in a non-lazy way. You said that it's important in your response above, but can you elaborate on why this is important?

Comment by Jeremy Mikola [ 07/Dec/17 ]

It is important to check whether sessions are supported at the time startSession is called.

jesse: This may be relevant for libmongoc. AFAIK, mongoc_client_start_session() performs no IO when constructing a client session (possibly evidenced by cluster time defaulting to an empty value).

Comment by Robert Stam [ 07/Dec/17 ]

It is important to check whether sessions are supported at the time startSession is called.

When an application calls startSession and sessions are not supported the error should be reported immediately to the caller of startSession, not at some arbitrary future time.

Knowing whether sessions are supported is also relevant at the time an implicit session is created. For example, the .NET driver uses the knowledge of whether sessions are supported or not to either create a real implicit session or a dummy one.

Generated at Thu Feb 08 08:24:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.