-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENG-9317 Fix concurrent workflow create bug #342
ENG-9317 Fix concurrent workflow create bug #342
Conversation
…ead to avoid concurrency error due to level serializable being overly strict Signed-off-by: Kelly Deng <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #342 +/- ##
=======================================
Coverage 23.79% 23.79%
=======================================
Files 14 14
Lines 1244 1244
=======================================
Hits 296 296
Misses 928 928
Partials 20 20 Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I am a bit concerned about lowering the isolation level. Think the only potential negative test case here is the outcome of 2+ concurrent provisioning of the same bare metal. Something that team discussed and is guarded at the inventory level.
The tests here show the isolation level "Repeatable Read" does indeed solve for the DB concurrency issue without a decent amount of code change.
Think this is an acceptable risk. Feedback and other suggestions welcomed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Ran this branch locally and tested with parallels and saw no issues.
## Description When multiple process concurrently create workflow, the code to access workflow_worker_map is not concurrent safe. This PR fix this issue. ## Why is this needed During workflow creation, new rows may be add to table `workflow_worker_map` in the same transaction. The original design use ` INSERT ... SELECT`. This doesn't work concurrently with SERRIELIZABLE isolation. Fixes: # - Create unique index on workflow_worker_map table - Use `INSERT ... ON CONFLICT DO NOTHING;` to avoid table lock. ## How Has This Been Tested? Manually as #342. ## How are existing users impacted? What migration steps/scripts do we need? - No impact - database migrate to 202010221010-add-unique-index. ## Checklist: I have: - [ ] updated the documentation and/or roadmap (if required) - [ ] added unit or e2e tests - [ ] provided instructions on how to upgrade
Signed-off-by: Kelly Deng [email protected]
Description
Lowers the transaction isolation level from
serializable
torepeatable read
asserializable
appears to be too overly strict.Why is this needed
When creating several workflows in parallel, an error is returned:
example:
inputs
file contentsFixes: #
How Has This Been Tested?
Manually, using parallel to run workflow create commands in parallel
Lowering the isolation level to
repeatable read
and using the sameinput
file from above, the workflow create commands succeed without error:How are existing users impacted? What migration steps/scripts do we need?
No migration needed.
Checklist:
I have: