[SERVER-31777] Explicitly deactivate logical sessions under FCV34 Created: 31/Oct/17  Updated: 30/Oct/23  Resolved: 09/Nov/17

Status: Closed
Project: Core Server
Component/s: Upgrade/Downgrade, Write Ops
Affects Version/s: None
Fix Version/s: 3.6.0-rc4

Type: Bug Priority: Major - P3
Reporter: Shane Harvey Assignee: Mira Carey
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-11012 Docs for SERVER-31777: Explicitly dea... Closed
Duplicate
is duplicated by SERVER-31738 fcv34 should suppress logicalSessionT... Closed
Related
is related to SERVER-31900 Logical session error message states ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Platforms 2017-11-13
Participants:

 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 [ 09/Nov/17 ]

Author:

{'name': 'Jason Carey', 'username': 'hanumantmk', 'email': 'jcarey@argv.me'}

Message: SERVER-31777 deactivate logical sessions for fcv34

For anything less than fully upgraded to 3.6:

Generated at Thu Feb 08 04:28:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.