[SERVER-49836] Handle sessions commands during tenant migrations Created: 23/Jul/20  Updated: 06/Dec/22  Resolved: 19/Nov/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Do Votes: 0
Labels: pm-1791_milestone-A
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

TheĀ  sessions commands are:

  • endSessions
    • adds the sessions to the mongod's LogicalSessionCache's _endingSessions
    • the config.system.sessions docs will be removed the next time the mongod does its periodic LogicalSessionCache refresh
  • kill*Sessions
    • aborts the transactions associated with the session
    • closes open cursors associated with the session
    • kills operations associated with the session
  • refreshSessions
    • updates the session's "lastUse" in the mongod's LogicalSessionCache
    • the config.system.sessions docs will be updated the next time the mongod does its periodic LogicalSessionCache refresh
  • startSession
    • generates a UUID for the session
    • adds the session to the mongod's LogicalSessionCache
    • the config.system.sessions doc will be inserted the next time the mongod does its periodic LogicalSessionCache refresh
    • returns the UUID


 Comments   
Comment by Esha Maharishi (Inactive) [ 19/Nov/20 ]

Thanks! I'm going ahead and closing as Won't Do, but judah.schvimer feel free to comment if you think differently.

Comment by Andy Schwerin [ 19/Nov/20 ]

That matches my understanding.

On Wed, Nov 18, 2020 at 9:53 PM Esha Maharishi (Jira) <jira@mongodb.org>

Comment by Esha Maharishi (Inactive) [ 19/Nov/20 ]

Only the endSessions and refreshSessions commands are supported in API Version 1 (startSession and kill*Sessions are not supported).

The question is, is it safe for these commands to execute on the donor and return success to the client, even if the tenant has been migrated away?

First, note that endSessions and refreshSessions are best-effort only: they only update the mongod's in-memory LogicalSessionCache before returning, and the in-memory LogicalSessionCache is lost on restart.

However, if we assume no node is restarted:

endSessions' effect is that the config.system.sessions entries are deleted sooner than their TTL, allowing the corresponding config.transactions state to be reaped sooner as well. If endSessions executes on the donor instead of the recipient and returns success, all that happens is the sessions' state is reaped slightly later than it could be.

refreshSessions' effect is to bump the TTL date for the config.system.sessions entries, which will keep the corresponding config.transactions state around longer. The risk in refreshSessions executing on the donor instead of the recipient is that the recipient will garbage collect state sooner than the client would expect. As a result, the client may get back IncompleteTransactionHistory when they retry a write or commitTransaction, even though they think they have kept their session alive. For this to occur, the client would have to do a write, then for at least 30 minutes continue using the session without doing more writes, then retry the write. Since this is unlikely and has a relatively harmless effect on the client, we consider it acceptable.

So, we can close this as Won't Do and not synchronize sessions commands with tenant migrations.

schwerin, judah.schvimer, can you confirm this matches your understanding from the 6 week review?

Generated at Thu Feb 08 05:20:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.