track loaded sessions to enable concurrent access #37
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This moves to a pattern of tracking loaded sessions via a hash set. By doing so, we can share sessions concurrently. In other words, we no longer need a lock to protect the session for the duration of the request and instead are able to share sessions between concurrent tasks. Why do we need this at all? A data race can otherwise occur when a session has been loaded but its modifications have not been stored. For instance, another task may load the session from the store in the meantime and this load will overwrite pending modifications as it will effectively replace the session in memory. One solution to this problem is to lock the request, as we've done in a stopgap capacity. This unscalable at present and even when refined, i.e. to lock per session as opposed for all sessions, limits concurrency over the session itself. In practice, sessions can only be operated on serially and are not available concurrently. A more flexible approach is implemented here, allowing for concurrent memory access by limiting loads from the store to situations where no session exists in the loaded set. Put another way, sessions are tracked such that they can be used instead of loading from the store thus ensuring that pending modifications are not lost by a load. See #36 for more details about the stopgap locking behavior; this replaces that approach altogether.
Codecov Report
@@ Coverage Diff @@
## main #37 +/- ##
==========================================
+ Coverage 77.77% 79.21% +1.43%
==========================================
Files 13 13
Lines 423 433 +10
==========================================
+ Hits 329 343 +14
+ Misses 94 90 -4
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This moves to a pattern of tracking loaded sessions via a hash set. By doing so, we can share sessions concurrently. In other words, we no longer need a lock to protect the session for the duration of the request and instead are able to share sessions between concurrent tasks.
Why do we need this at all? A data race can otherwise occur when a session has been loaded but its modifications have not been stored. For instance, another task may load the session from the store in the meantime and this load will overwrite pending modifications as it will effectively replace the session in memory.
One solution to this problem is to lock the request, as we've done in a stopgap capacity. This unscalable at present and even when refined, i.e. to lock per session as opposed for all sessions, limits concurrency over the session itself. In practice, sessions can only be operated on serially and are not available concurrently.
A more flexible approach is implemented here, allowing for concurrent memory access by limiting loads from the store to situations where no session exists in the loaded set. Put another way, sessions are tracked such that they can be used instead of loading from the store thus ensuring that pending modifications are not lost by a load.
See #36 for more details about the stopgap locking behavior; this replaces that approach altogether.