This is an automated email from the ASF dual-hosted git repository.
tkobayas pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-kie-docs.git
The following commit(s) were added to refs/heads/main by this push:
new 851f754a2 [incubator-kie#7210] update sequential mode explanation
(#4604)
851f754a2 is described below
commit 851f754a2c8b327070e62a208be37b8dce6a5acd
Author: Toshiya Kobayashi <[email protected]>
AuthorDate: Tue Oct 27 17:36:32 2026 +0900
[incubator-kie#7210] update sequential mode explanation (#4604)
* update sequential mode explanation
* copilot suggestions
---
.../ROOT/pages/rule-engine/_phreak-sequential-mode-con.adoc | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
a/drools-docs/src/modules/ROOT/pages/rule-engine/_phreak-sequential-mode-con.adoc
b/drools-docs/src/modules/ROOT/pages/rule-engine/_phreak-sequential-mode-con.adoc
index 55ec41a1c..65fa34ba2 100644
---
a/drools-docs/src/modules/ROOT/pages/rule-engine/_phreak-sequential-mode-con.adoc
+++
b/drools-docs/src/modules/ROOT/pages/rule-engine/_phreak-sequential-mode-con.adoc
@@ -21,9 +21,9 @@ with the License. You may obtain a copy of the License at
= Sequential mode in Phreak
-Sequential mode is an advanced rule base configuration in the {RULE_ENGINE},
supported by Phreak, that enables the {RULE_ENGINE} to evaluate rules one time
in the order that they are listed in the {RULE_ENGINE} agenda without regard to
changes in the working memory. In sequential mode, the {RULE_ENGINE} ignores
any `insert`, `modify`, or `update` statements in rules and executes rules in a
single sequence. As a result, rule execution may be faster in sequential mode,
but important update [...]
+Sequential mode is an advanced rule base configuration in the {RULE_ENGINE},
supported by Phreak. In sequential mode, the {RULE_ENGINE} evaluates rules in
salience order and does not re-evaluate any rule's conditions after it has been
evaluated, even if working memory changes. A rule can still fire multiple times
if it has multiple matching fact combinations, but no rule is re-activated by
later changes. Because this removes inference (iterative re-evaluation of rules
based on changes), [...]
-Sequential mode applies to only stateless KIE sessions because stateful KIE
sessions inherently use data from previously invoked KIE sessions. If you use a
stateless KIE session and you want the execution of rules to influence
subsequent rules in the agenda, then do not enable sequential mode. Sequential
mode is disabled by default in the {RULE_ENGINE}.
+Sequential mode applies to only stateless KIE sessions because stateful KIE
sessions inherently use data from previously invoked KIE sessions. Sequential
mode is disabled by default in the {RULE_ENGINE}.
To enable sequential mode, use one of the following options:
@@ -60,3 +60,11 @@ When you enable sequential mode, the {RULE_ENGINE} evaluates
rules in the follow
Because the left-input tuple memory is disabled, the tuples propagate down the
network and are joined with the right-input objects, but they are not retained
in the left input.
The right-input node memories are the same as in the default mode: Phreak uses
indexed memories when the constraints can be indexed, and an object list
otherwise.
+
+== Behavior of `modify`, `update`, `insert`, and `delete` in sequential mode
+
+In the typical use of sequential mode, rules only read facts and do not use
`modify`, `update`, `insert`, or `delete` in their consequences (right-hand
side). In this case, all rules see the facts exactly as they were when
initially asserted, before any rule consequences run.
+
+However, using `modify`, `update`, `insert`, or `delete` in consequences is
also supported as an advanced technique. The change takes effect immediately:
rules not yet evaluated will see the updated, newly inserted, or deleted facts
when their turn comes. A rule that has already been evaluated is not
re-evaluated, even if the change would have affected its conditions.
+
+NOTE: Beta node sharing is automatically disabled in sequential mode to ensure
that `modify` or `update` in a rule's consequence produces correct results.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
