Why? As opus states, this is the job of Persistence and the restoreOnStartup strategy. Theoretically (there is a bug right now that makes what I’m about to write not always true), your Items should be restored to their state before any of your rules start running. So there is no need to wait.
Again why? A better approach would be to have only one Rule and the first half of the Rule load your values from the file and the second half have the code that depends on those values having been loaded.
You should not have more than one Rule that has the same trigger if they are actually independent. Since these two Rules are dependent on each other, it is better to combine them into the same Rule. If you are an experienced programmer, this is one of the many areas you will have frustration with the Rules DSL. If you are an experienced developer I would recommend the JSR223 Rules that will let you write Rules in a less constrained language like Jython, JavaScript, or Groovy.
Rules are not functions. Problems will occur if you try to treat them as if they were. Rules encapsulate the actions to take place when a given event occurs.
Now, there are work arounds including (in order of preference):
-
Design Pattern: Separation of Behaviors : have the Rule that loads the data from file generate an event (e.g Design Pattern: Proxy Item) to trigger the second Rule
-
Scripts: put the body of each Rule in a separate Script and call those from one System started Rule
-
Reusable Functions: A simple lambda example with copious notes : put the bodies of the two Rules into two lambdas that get called from a single System started Rule.
But Rule runtime threads are a limited resource. There are only five in the thread pool by default. This means you can only run up to five Rules at the same time. And if you have a Rule that potentially never returns, like Vincent said, that makes that thread permanently unavailable. If you run out of all five threads no Rules can run. So you should avoid at all costs any Rules that can potentially never return like an indeterminate while loop. Design Pattern: Looping Timers is a better approach because the Rule doesn’t sit around consuming a runtime thread doing nothing freeing up the thread for other Rules to use.