Do not run multiple child strands inside donate #3493
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
Running multiple child strands inside donate can lead to a situation where one or more child progs successfully complete, and a later child prog fails, and the failure of the later child prog rolls back the database changes made by the child progs that successfully complete. If the child progs are not idempotent, this results in a situation that cannot be fixed without manual intervention. Instead, as soon as a child is successfully run inside donate, nap for 0 seconds. That will mean the remaining child strands are skipped during that donate method. The Nap flow control exception will be caught inside Strand#unsynchronized_run. The parent will update it's own schedule, and the transaction will commit. Strand#run will handle the Nap 0 exception and if the deadline hasn't passed, it will immediately rerun the strand. Assuming the strand still has child processes to run, that will likely get back to the donate call, where the next child strand will run, repeating this process until the deadline has passed, all child strands have run, or there is an error running a child strand.
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.
Running multiple child strands inside donate can lead to a situation where one or more child progs successfully complete, and a later child prog fails, and the failure of the later child prog rolls back the database changes made by the child progs that successfully complete. If the child progs are not idempotent, this results in a situation that cannot be fixed without manual intervention.
Instead, as soon as a child is successfully run inside donate, nap for 0 seconds. That will mean the remaining child strands are skipped during that donate method. The Nap flow control exception will be caught inside Strand#unsynchronized_run. The parent will update it's own schedule, and the transaction will commit. Strand#run will handle the Nap 0 exception and if the deadline hasn't passed, it will immediately rerun the strand. Assuming the strand still has child processes to run, that will likely get back to the donate call, where the next child strand will run, repeating this process until the deadline has passed, all child strands have run, or there is an error running a child strand.
Important
Modify
donateinprog/base.rbto nap after each successful child run, preventing rollback of successful transactions if a later child fails, and add corresponding tests.donateinprog/base.rbto nap for 0 seconds after each successful child strand run, preventing rollback of successful transactions if a later child fails.failermethod inprog/test.rbto simulate failure in child strands.base_spec.rbto ensure failure of one child strand does not affect others indonatemethod.prog/test.rbto support new test scenarios.This description was created by
for 1b771a1. You can customize this summary. It will automatically update as commits are pushed.