[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:
|
| 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? |