I have a workflow which spawns multiple child workflows. There could be a lot of child workflows spawned over the life of the parent. I want to keep track of any active children, so I can wait for active children to terminate in some instances.
I believe a simple way to handle this is to have a set of active child workflow IDs and then have each child signal to the parent when it is done (whether successful or failed) and have the signalMethod remove this child from the set.
If multiple signals come in at the same time is there any possibility that the set may be modified inconsistently due to some race condition? Or are signals processed sequentially as they come in? And if the main workflow is adding new workflow IDs to the set as signals are coming in for other completed workflows, will there be any risk of inconsistent modification?
Signals are processed in the same order as they appear in the workflow history. Java SDK relies on cooperative multi-threading. Only one thread is executing at the time, so no explicit synchronization is needed. Check out the sliding window batch sample that implements the pattern you describe.
If the parent is not calling continue-as-new, then using Promises to wait for children to complete eliminates the need for signaling.
Thanks for the quick reply! The parent is calling continueAsNew. I only want to wait for children jobs to finish at certain “checkpoints”. Otherwise if I wait around for a batch of child jobs to complete, it’s possible that I might be late on submitting other child jobs.
Sounds like I should be fine to implement it as a simple shared object that can get added to/removed from
Temporal SDK calls signal handlers in the order in which they are recorded in the history. Your code can process them in any order that matches your requirements.