[rules-users] How to break the rules execution if one has been satisfied ??

Fri Jun 11 08:27:15 EDT 2010

Another thing to remember is that activations occurs when you
insert/update/retract facts and the execution itself happens when you call
fireAllRules() ( or fireUntilHalt() ).

2010/6/11 Swindells, Thomas <TSwindells at nds.com>

>  You technical description isn’t at all accurate.
>
> You need to read up on Rete Trees, I’m still a bit vague on them myself but
> a hopefully slightly more accurate description is as follows:
>
> When the rules are compiled each of their conditions is converted to a node
> on the graph.  If rules share the same initial set of conditions then they
> will share those nodes in the tree.  These nodes contain references to the
> data in the working memory that they match against.  When an object is added
> or updated in working memory then the knowledge of this allows just the
> relevant nodes to be re-evaluated trickling down the tree.  If a leaf node
> is reached with a particular set of Objects then this means that the rule
> can then be placed on the activation queue with that set of data.
>
>
>
> This Rete graph is designed to solve the problem you are describing which
> is why we have a rules engine rather than doing the naive procedural
> implementation of ‘firing rules’.  Of course if all your rules are disjoint
> but rely on the same set of Objects then there isn’t any choice but to
> evaluate all the rules, after all they may all do different things and
> normally you want multiple rules to fire.
>
>
>
> How you write your rules can also have a massive impact on performance and
> the shape of the graph (which you can see in eclipse), are you worrying
> about this purely from a theoretical viewpoint or are you having a concrete
> performance problem?
>
>
>
> Hope this helps your understanding,
>
>
>
> Thomas
>
>
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *Nikhil S. Kulkarni
> *Sent:* 11 June 2010 12:27
> *To:* rules-users at lists.jboss.org
> *Subject:* [rules-users] How to break the rules execution if one has been
> satisfied ??
>
>
>
> Hi,
>
>
>
> In rules, in a particular rule set, all the when’s are executed. In
> technical terms, the activation is first created. For all the rules in a
> rule set the when condition is first evaluated and if the when condition is
> satisfied for any rule then the rule is marked as ready to fire. Once all
> the when part for all the rules are evaluated then all the ones that were
> marked for fire are fired.
>
> The performance issue that if there are some 1500 rows. Hence, when the
> rule is fired there are 1500 when conditions that are firstly checked. And
> only after this the then part is fired. There is no way to break the when
> checks on successful satisfaction of a particular rule when.
>
>
>
> Example:
>
> If I have say a group of 1000 rules as mentioned below
>
>
>
> Rule_1
>
> Salience 1000
>
> When
>
>                 Some_Conditions_1
>
> Then
>
>                 Some_Actions_1
>
>
>
> Rule_2
>
> Salience 999
>
> When
>
>                 Some_Conditions_2
>
> Then
>
>                 Some_Actions_2
>
> .
>
> .
>
> .
>
> Rule_1000
>
> Salience 1
>
> When
>
>                 Some_Conditions_1000
>
> Then
>
>                 Some_Actions_1000
>
>
>
> Let’s assume that Some_conditions_2 = true
>
> Now even though I have an ordering using salience, the rule engine will
> still execute all the when conditions (Some_Conditions_1 ..
> Some_Conditions_1000)
>
>
>
> Is it possible for me to break this when evaluation even if one has been
> satisfied?
>
>
>
>
>
>
>
> Thanks & Regards,
>
> Nikhil S. Kulkarni
>
>
>
>
>
>
> MASTEK LTD.
> Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List.
> In the US, we're called MAJESCOMASTEK
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> ------------------------------
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmaster at nds.com and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes. To protect the environment please do not
> print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
> 4EX, United Kingdom. A company registered in England and Wales. Registered
> no. 3080780. VAT no. GB 603 8808 40-00
>
> **************************************************************************************
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>

-- 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Esteban Aliverti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100611/288c2497/attachment.html 