[SERVER-67723] SessionCatalogMongoD reaper can interrupt expired internal transaction sessions for retryable writes that are still in use Created: 01/Jul/22  Updated: 29/Oct/23  Resolved: 07/Jul/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.1, 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: Cheahuychou Mao
Resolution: Fixed Votes: 0
Labels: sharding-nyc-subteam3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v6.0
Sprint: Sharding 2022-07-25
Participants:
Linked BF Score: 21

 Description   

The SessionCatalogMongoD reaper has the logic for deleting the on-disk state for every expired internal transaction session for retryable write that it think is no longer in use, regardless of whether its corresponding logical session has expired. To determine if an expired transaction session is still in use, it relies this set of expired transaction sessions not reaped from the SessionCatalog. The limitation around this is that the set only gets populated with expired transaction session ids whose logical session has expired and been removed from the config.system.sessions collection. So if a logical session hasn't expired but its latest internal transaction session for retryable write has expired (*), the reaper would delete the on-disk of that transaction session and that would cause any operation running on that transaction session to get interrupted. One of the few rare cases where (*) can happen is where the transaction has committed or aborted but is stuck waiting for write concern. This showed up in BF-25724 as this test sets the TransactionRecordMinimumLifetimeMinutes to 0 (default 30 mins). 

One solution is to make the SessionCatalogMongoD reaper not delete the on-disk state for any expired internal transaction session for retryable write until its logical session has expired just like it does for all other kinds of transaction sessions. That is, we will completely rely on the best-effort eager reaping in the SessionCatalog to delete the on-disk state for internal transaction session for old retryable writes. 



 Comments   
Comment by Githook User [ 27/Jul/22 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'mao.cheahuychou@gmail.com', 'username': 'cheahuychou'}

Message: SERVER-67723 Make the SessionCatalogMongoD reaper not delete the on-disk state for any transaction session until its logical session has expired

(cherry picked from commit 338062b6a22668dcb1cf919de5dd2e9f3eea0221)
Branch: v6.0
https://github.com/mongodb/mongo/commit/83b60779ae6a5f0b80c4a50d175de97e2a91082c

Comment by Githook User [ 07/Jul/22 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'mao.cheahuychou@gmail.com', 'username': 'cheahuychou'}

Message: SERVER-67723 Make the SessionCatalogMongoD reaper not delete the on-disk state for any transaction session until its logical session has expired
Branch: master
https://github.com/mongodb/mongo/commit/338062b6a22668dcb1cf919de5dd2e9f3eea0221

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