[SERVER-66960] Don't lock session catalog to find highest child txnNumber to refresh transaction participant Created: 02/Jun/22  Updated: 29/Oct/23  Resolved: 02/Jun/22

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

Type: Improvement Priority: Major - P3
Reporter: Jack Mulrow Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Backport Requested:
v6.0
Sprint: Sharding NYC 2022-06-13
Participants:

 Description   

Currently a transaction participant will get the highest txnNumber the SessionCatalog has seen for any transaction in the current logical session when refreshing the participant from disk. This is to avoid reading more config.transactions entries than necessary. This is gotten from the SessionRuntimeInfo of the participant's session from the SessionCatalog. By this point, the participant has already checked out the session once, so we should be able to avoid looking back into the SessionCatalog (and locking its mutex) by caching the highest seen txnNumber onto the participant's Session, which is accessible directly in the transaction participant code.



 Comments   
Comment by Githook User [ 02/Jun/22 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-66960 Cache highest child txnNumber on checked out sessions

(cherry picked from commit b2f773225a555d581e547527a8cb67bdeed7fadc)
Branch: v6.0
https://github.com/mongodb/mongo/commit/5fc426665b3579c7ed58d6db2eb64279d7ae34e6

Comment by Githook User [ 02/Jun/22 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-66960 Cache highest child txnNumber on checked out sessions
Branch: master
https://github.com/mongodb/mongo/commit/b2f773225a555d581e547527a8cb67bdeed7fadc

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