[rules-users] lock-on-active documentation

[Wolfgang Laun]

Proposed change:

Whenever a ruleflow-group becomes active or an agenda-group receives the
focus,
any rule within that group that has lock-on-active set to true will not be
activated
any more; irrespective of the origin of the update, the activation of a
matching
rule is discarded. This is a stronger version of no-loop, because the change
could now be caused not only by the rule itself. It's ideal for calculation
rules where
you have a number of rules that modify a fact and you don't want any rule
re-matching and firing again. Only when the ruleflow-group is no longer
active or the
agenda-group loses the focus those rules with lock-on-active set to true
become
eligible again for their activations to be placed onto the agenda.

OK?
-W


On Sun, Mar 15, 2009 at 2:24 PM, Edson Tirelli <tirelli at post.com> wrote:

>
>    Wolfgang,
>
>    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
> agenda.
>
>    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.
>
>    You are right. Docs are not clear. Thank you for helping.
>
>    Edson
>
> 2009/3/15 Wolfgang Laun <wolfgang.laun at gmail.com>
>
>> From Drools-5.0.0, Expert, 7.8.1. Sentence numbers added by me:
>>
>> [1] when a ruleflow-group becomes active or an agenda-group receives the
>> focus
>> any rules that have lock-on-active set to try cannot place activations
>> onto the
>> agenda, the rules are matched and the resulting activations discarded.
>> [2] This is a stronger version of no-loop.
>> [3] It's ideally for calculation rules where you have a number of rules
>> that
>> will modify a fact and you don't want any rule re-matching and firing.
>> [4] 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
>> rules
>> with the attribute set to true.
>> [5] 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.
>>
>>
>> [4] says that activations "for the rules with the attribute set to true"
>> are
>> disallowed. This is confusing or even in contradiction with [1], 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.)
>>
>> [5] 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
>> lock-on-active setting?
>>
>> [1] s/when/When/, s/try/true/
>>
>> I would create a JIRA, but I'd like to be sure what to suggest for a fix.
>> -W
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
>
> --
>  Edson Tirelli
>  JBoss Drools Core Development
>  JBoss, a division of Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090315/5c78941a/attachment.html