[DOCS-11012] Docs for SERVER-31777: Explicitly deactivate logical sessions under FCV34 Created: 14/Nov/17  Updated: 29/Oct/23  Resolved: 05/Dec/17

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 3.6.0-rc4

Type: Task Priority: Major - P3
Reporter: Kay Kim (Inactive) Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-31777 Explicitly deactivate logical session... Closed
Participants:
Days since reply: 6 years, 10 weeks, 2 days ago
Epic Link: DOCS: 3.6 Server
Story Points: 0.25

 Description   

Documentation Request Summary:

This causes all commands to fail which pass lsid under fcv 3.4

Also prevents isMaster from return logicalSessionTimeoutMinutes under fcv 3.4

Engineering Ticket Description:

As jmikola explained in SPEC-974:

In the case of feature compatibility being downgraded, I believe there is still a risk that the client believes a server supports sessions (and retryable writes) when it does not.

Consider that when SDAM is initialized, a driver monitors a primary and sees wire version and logicalSessionTimeoutMinutes, which indicates that the server is feature compatibility 3.6. The driver executes a write command that includes the lsid and txnNumber fields. The response for that command is lost in transit, and the driver needs to retry. Before a retry attempt can be made, the server is downgraded to feature compatibility mode 3.4. The retried write command includes the same lsid and txnNumber. The primary, operating in 3.4 feature compatibility mode, will ignore these fields and apply the write a second time.

The above example considers a downgrade between the first and retry attempt, but a similar race condition exists if the downgrade were to happen between the driver's last monitoring round (issuing isMaster commands) and the write's first attempt.

I think at least one of the following may ensure that there is no risk of ever applying a write multiple times:

  • The server must close its connections when the feature compatibility mode is downgraded.
  • A 3.6 server should raise an error if a write command includes lsid and txnNumber and feature compatibility mode 3.6 is not enabled.

I believe the error reporting in the second bullet is worth implementing regardless. That would be consistent with what is already done when commands include a collation option on a 3.4 server, and the server does not have feature compatibility mode 3.4 enabled.

Additionally, a 3.6 server operating in FCV 3.4 should suppress logicalSessionTimeoutMinutes from its isMaster response (as originally reported in SERVER-31738).



 Comments   
Comment by Githook User [ 05/Dec/17 ]

Author:

{'username': 'kay-kim', 'email': 'kay.kim@10gen.com', 'name': 'kay'}

Message: DOCS-11012: update isMaster for fcv
Branch: master
https://github.com/mongodb/docs/commit/df470e8f84b14a9e006f681acb6e2286a5d6c108

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