Proposed change:<br> <br><a>Whenever a ruleflow-group becomes active or an agenda-group
receives the focus,<br>any rule within that group that has lock-on-active set to true will not be activated<br>any more; irrespective of the origin of the update, the activation of a matching<br>rule is discarded. This is a stronger version of no-loop, because the change<br>
could now be caused not only by the rule itself. It&#39;s ideal for calculation rules where<br>you have a number of rules
that modify a fact and you don&#39;t want any rule<br>re-matching and
firing again. Only when the
ruleflow-group is no longer active or the<br>agenda-group loses the focus
those rules with lock-on-active set to true become<br>eligible again for their activations to be placed onto the agenda.<br></a><br>OK?<br>-W<br><br><br><div class="gmail_quote">On Sun, Mar 15, 2009 at 2:24 PM, Edson Tirelli <span dir="ltr">&lt;<a href="mailto:tirelli@post.com">tirelli@post.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>   Wolfgang,<br><br>   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.<br>

<br>   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 agenda.<br><br>   Regarding your question of [4], 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.<br>

<br>   You are right. Docs are not clear. Thank you for helping.<br><br>   Edson<br><br><div class="gmail_quote">2009/3/15 Wolfgang Laun <span dir="ltr">&lt;<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"><a>From Drools-5.0.0, Expert, 7.8.1. Sentence numbers added by me:<br>
<br>[1] when a ruleflow-group becomes active or an agenda-group
receives the focus<br>any rules that have lock-on-active set to try cannot
place activations onto the<br>agenda, the rules are matched and the
resulting activations discarded.<br>[2] This is a stronger version of no-loop.<br>[3] It&#39;s ideally for calculation rules where you have a number of rules
that <br>will modify a fact and you don&#39;t want any rule re-matching and
firing.<br>[4] In summary fire these currently active rules and only these
rules, no<br>matter how the data changes, do not allow any more
activations for the rules<br>with the attribute set to true.<br>[5] When the
ruleflow-group is no longer active or agenda-group loses the<br>focus
those rules with lock-on-active set to true can once again add<br>activations onto the agenda.<br><br><br>[4] says that activations &quot;for the rules with the attribute set to true&quot; are<br>disallowed. This is confusing or even in contradiction with [1], which I<br>



understand to mean that WM updates done by the RHS of a rule X with<br>lock-on-active==true don&#39;t result in any activations. (Of course, this<br>includes activations of X itself.)<br><br>[5] is absolutely confusing: How can rules in a group that isn&#39;t active<br>



or doesn&#39;t have the focus can add activations - irrespective of its<br>lock-on-active setting?<br><br></a><a>[1] s/when/When/, s/try/true/</a><a><br><br>I would create a JIRA, but I&#39;d like to be sure what to suggest for a fix.<br>


-W<br><br></a>
<br></div></div>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>  Edson Tirelli<br>  JBoss Drools Core Development<br>  JBoss, a division of Red Hat @ <a href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>

</font><br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br>