Attempt to obtain new locks without retrying transaction in ZSTM #9221
Conversation
This file contains hidden or 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
ghostdogpr
reviewed
Sep 25, 2024
| test("doesn't deadlock under concurrency when transactions create new ZSTMs - i9215") { | ||
| def transaction(arr: TArray[String]) = | ||
| ZSTM.suspend { | ||
| Thread.sleep(1) // Force ZSTM lock contention |
There was a problem hiding this comment.
Looks like it fails with Scala.js despite the except aspect
There was a problem hiding this comment.
Aghh the except part is for nonFlaky. Seems that ScalaJS doesn't like the Thread.sleep part, I'll move the test to be run for JVM/Native only
|
Native doesn't like it either? Or it's just flaky? |
Seems like an issue with GC. I changed the test to run on JVM only for the time being |
ghostdogpr
approved these changes
Sep 26, 2024
<
8375
div class="ml-md-2 mt-md-0 mt-2 flex-shrink-0">
View reviewed changes
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.
/fixes #9215
The issue is that in cases where a transaction creates ZSTMs internally, if there is contention and we reach the
MaxRetriessection, the ZSTM loop will keep retrying because the locks will be changing on each iteration.With this PR we attempt to obtain the diff in locks while we still hold the "outer" locks. This fixes the issue but is also more performant as we're not retrying the entire transaction in cases where we can acquire the additional locks