Check rule conditions serially instead of in parallel

[robross0606]

We're running into issues where our facts are based on transactional access to a database. When we try to properly decompose our rules into multiple facts, we hit problems where the same transaction is trying to be used simultaneously because the rules engine appears to process facts in parallel by default.

I know there's a way to set priority on rules and facts which should make them run serially. The issue with this approach Is that is appears to be declarative on the fact itself and not on the user of the fact when constructing rule conditions. This makes it hard to use when you may want to decompose rule conditions in different order but still have them run serially instead of in parallel.

[robross0606]

Ideally there would be a way to tell the engine to process rule conditions in order, either by setting priority on each condition, or simply by telling the engine "all in order".

[robross0606]

Another possibility would be to add a "before" operator or something like that because fact comparisons also force facts to be run in order instead of in parallel. The problem is, in this case, we have no direct comparison between our facts. Just that they cannot be derived in parallel.

[StingyJack]

a "depends on" mapping may be the easiest and would allow for all serial, all parallel, or a mix of both.

[robross0606]

@StingyJack Is there a good example of this somewhere?

[StingyJack]

nuget / npm dependencies. If a condition depends on another condition, then those must be done in order (serially). The rest can be parallel processed

[robross0606]

@StingyJack are you suggesting an alternate way to implement the enhancement or suggesting this feature already exists in the library?

[StingyJack]

I'm suggesting a way that we are probably going to have to implement. Unfortunately this will be in a fork and not here because we can't wait an indefinite time for the PR to be approved or risk that it doesn't. Per current company policy that will be a private fork (for now, that can change)

[robross0606]

this will be in a fork and not here

Has any work been done on this anywhere yet?

[StingyJack]

After a bit more experience and research with this and other rules engines, when I read the original post now I see what looks like a rather large red flag due with the mention of "transaction". Since transactions are usually necessary for when you need to change data and the purpose of a rule engine is to provide knowledge or information (but not to actually perform the actions). how does the one affect or interfere with the other?

The steps could be something like

• some service gets fact data from the db, opening transaction if there is potential for modification
• service sends fact data for rule evaluation and gets instruction of what to do for that data
• service executes action, including either commit or rollback of transaction

Are you doing something like that or something else?

[robross0606]

No, this isn't changing data as you would think it does. The system includes a "lazy copy" mechanism that assigns unique identifiers on-the-fly, which requires transactions but doesn't impact the domain data against which rules are applied. The domain data is stable. The bottom line is the same. We need to evaluate rule facts serially instead of in parallel.

[robross0606]

The steps could be something like

• some service gets fact data from the db, opening transaction if there is potential for modification
• service sends fact data for rule evaluation and gets instruction of what to do for that data

This is something like what we do already. The problem is that the effort around "some service gets fact data" effectively replaces the point of using json-rules-engine to begin with. We cannot decompose facts properly and compose them into different rules if we cannot specify that some facts must be retrieved serially instead of all being done in parallel. That means basically collapsing each mixture of facts into a single fact with lots of code. At that point, what role would json-rules-engine really play?

json-rules-engine already almost supports this via priority settings. What's missing is that priority is declarative on a rule or fact itself which means it cannot be changed relative to another fact if the priorities relative to each other need to be different on different rules. It is a matter of flexible composition of facts into various rules.