-
Type: New Feature
-
Resolution: Fixed
-
Priority: Minor - P4
-
Affects Version/s: None
-
Component/s: None
-
None
-
RSS Sydney
-
Fully Compatible
-
SleighTheDay - 2024-12-24, SongingMoose - 2025-01-07, NamePending - 2025-01-21, MooseOnTheLoose - 2025-02-04
The WT_SESSION object is not thread safe. We’ll need to implement locking around calling methods on the WT_SESSION in the server as the rollback handler can try to call WT_SESSION::rollback_transaction() on a WT_SESSION concurrently. The server has a wrapper for WT_SESSION called WiredTigerSession. We can implement the equivalent WT_SESSION methods in this wrapper and add locking around the API calls to keep the locking internalized and only around the critical section. For the most part, only a single thread will be accessing the WT_SESSION at any given time, until its transaction needs to be rolled back by WiredTiger, typically under cache pressure. So we shouldn’t expect contention on a per-session lock during steady state.
- depends on
-
SERVER-99539 Lock down WT_CONNECTION inside the WiredTigerConnection
- Backlog
-
SERVER-98541 migrate uses of open_session to the WiredTigerSession wrapper
- Closed
-
SERVER-98542 Add lint check to prevent directly using WT_SESSION
- Closed
-
SERVER-98909 Separate WiredTigerSession from the session cache
- Closed
-
SERVER-99541 Wrap session calls 1/n
- Closed
-
SERVER-99696 Wrap session calls 2/n
- Closed
-
SERVER-99923 Remove WiredTigerSession lock
- Closed
- is depended on by
-
SERVER-98121 Handle a rollback call from WiredTiger on the correct session
- Closed
- is duplicated by
-
SERVER-98087 Add concurrency control for accessing a single WT_SESSION from multiple threads
- Closed
- is related to
-
SERVER-98743 Ensure all WT_CURSOR API calls go through WiredTigerCursor and are thread-safe
- Closed
- split to
-
SERVER-99017 Wrap WT_SESSION::reconfigure
- Closed