-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Unknown
-
None
-
Component/s: Sessions
-
None
-
Needed
Summary
Drivers that only support MongoDB >=3.6, can remove logicalSessionTimeoutMinutes checking logic and assume all servers support sessions.
We have confirmed with the server team in HELP-35836 that there are no edge cases requiring special handling by the drivers, since even the lower FCV mode servers will not error when seeing an lsid.
Original Context:
The only remaining edge case to consider is direct connections to arbiters (non-data-bearing nodes). The spec currently has client.start_session raise an error when directly connected to an arbiter. jeff.yemin@mongodb.com and I propose we remove this limitation and defer to the arbiter to report an error if lsid is not supported. 3.6 arbiters report this error:
>>> with client.start_session() as s: ... client.local.system.views.find_one(session=s) ... Traceback (most recent call last):... raise OperationFailure(errmsg, code, response, max_wire_version) pymongo.errors.OperationFailure: cannot pass logical session id unless fully upgraded to featureCompatibilityVersion 3.6. See http://dochub.mongodb.org/core/3.6-feature-compatibility ., full error: {'ok': 0.0, 'errmsg': 'cannot pass logical session id unless fully upgraded to featureCompatibilityVersion 3.6. See http://dochub.mongodb.org/core/3.6-feature-compatibility .', 'code': 72, 'codeName': 'InvalidOptions'}
4.0+ arbiters appear to allow 'lsid':
>>> with client.start_session() as s: ... client.local.system.replset.find_one(session=s) ... {'_id': 'repl0', ...}
Note that 3.6 arbiters are always in the lower FCV mode:
The default in-memory value for FCV on mongod is 3.4, and it only gets set to 3.6 in the OpObserver when it sees an FCV document with the value 3.6, so since an arbiter is not data bearing, it will never see the document. We do not have a mechanism for arbiters to know the FCV of the replica set.
Motivation
This change will simplify implicit and explicit session creation and SDAM Topology updates by removing this section and the associated race conditions: https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#how-to-check-whether-a-deployment-supports-sessions
Is this issue urgent?
No
Is this ticket required by a downstream team?
No
Is this ticket only for tests?
No
- is related to
-
DRIVERS-2530 Do not perform server selection to determine sessions support
- Implementing
- related to
-
DRIVERS-759 Drivers may defer checking if a deployment supports sessions until the session's first operation
- Implementing
- split to
-
CXX-2592 Assume all >=3.6 servers support sessions
- Blocked
-
CDRIVER-4491 Assume all >=3.6 servers support sessions
- Blocked
-
CSHARP-4351 Assume all >=3.6 servers support sessions
- Blocked
-
GODRIVER-2576 Assume all >=3.6 servers support sessions
- Blocked
-
JAVA-4759 Assume all >=3.6 servers support sessions
- Blocked
-
MOTOR-1042 Assume all >=3.6 servers support sessions
- Blocked
-
NODE-4694 Assume all >=3.6 servers support sessions
- Blocked
-
PHPLIB-1004 Assume all >=3.6 servers support sessions
- Blocked
-
PYTHON-3462 Assume all >=3.6 servers support sessions
- Blocked
-
RUBY-3150 Assume all >=3.6 servers support sessions
- Blocked
-
RUST-1499 Assume all >=3.6 servers support sessions
- Blocked