The Rete algorithm eagerly reevaluate rules when changes are made to
data, does not matter if the rules belong to the active group or not. If a
rule in a non-active group is fully matched, it will be added to the agenda.
The difference is: rules in non-active groups are not allowed to *fire*, so
they will sit in the agenda until they are canceled by other changes to data
or their group becomes active, allowing them to fire.
Now, what lock-on-active does is: it prevents the fully matched rules on
active groups that contain lock-on-active to add the activation to the
Regarding your question of , does not matter who makes the change to
data. Even changes made by the application are caught by this scenario. The
scenario is: if the rule would add an activation of itself to the agenda,
but it has lock-on-active true and its group is active, the activation will
be discarded instead of added.
You are right. Docs are not clear. Thank you for helping.
2009/3/15 Wolfgang Laun <wolfgang.laun(a)gmail.com>
From Drools-5.0.0, Expert, 7.8.1. Sentence numbers added by me:
 when a ruleflow-group becomes active or an agenda-group receives the
any rules that have lock-on-active set to try cannot place activations onto
agenda, the rules are matched and the resulting activations discarded.
 This is a stronger version of no-loop.
 It's ideally for calculation rules where you have a number of rules
will modify a fact and you don't want any rule re-matching and firing.
 In summary fire these currently active rules and only these rules, no
matter how the data changes, do not allow any more activations for the
with the attribute set to true.
 When the ruleflow-group is no longer active or agenda-group loses the
focus those rules with lock-on-active set to true can once again add
activations onto the agenda.
 says that activations "for the rules with the attribute set to true"
disallowed. This is confusing or even in contradiction with , which I
understand to mean that WM updates done by the RHS of a rule X with
lock-on-active==true don't result in any activations. (Of course, this
includes activations of X itself.)
 is absolutely confusing: How can rules in a group that isn't active
or doesn't have the focus can add activations - irrespective of its
 s/when/When/, s/try/true/
I would create a JIRA, but I'd like to be sure what to suggest for a fix.
rules-users mailing list
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com