Hi Tom,

your understanding of "Activation" is fine, so let's see what happens if your rule "RS..." fires. (I'm abbreviating names.)

Initially, neither PolSet nor PolSetId are there, so "RS..." activation #1 is on the agenda, fires and executes the consequence.

Now, PolSet is created and inserted as a new fact. This causes reevaluation of all rules, including "RS..." (with its activation #1 still executing). The not(PolSet and PolSetId) is still true, and therefore the LHS yields true, and "RS..." activation #2 is put on the agenda. Continuing with #1, PolSetId is created and inserted, causing reevaluations of all rules. Now the not(PolSet and PolSetId) is false, so that "RS..." #2 is removed again.

As for a remedy, you might consider several approaches. Notice that I have to guess what else might be going on, so I could be way off with (3), for instance.

(1) Is it really necessary to have PolSet and PolSetId as two separate facts? (It might still be possible to have PolSet as an *object* for establishing linkage to the parental TransDet, without being a *fact*.)
(2) Add the rule attribute no-loop true to "RS..."
(3) If the absences of PolSetId alone is sufficient for triggering the rule(s), omit PolSet from rule "RS..." and add another rule which creates the "missing link" when you have a TransDet, the existence of at least one PolSetId and no matching PolSet, to create the latter.

Cheers
-W

2009/9/1 <Tom.E.Murphy@wellsfargo.com>
We have a fairly complex object model, but we’re still puzzled – I thought that the definition of “Activation” was that the data matched on all conditions of a rule, and therefore the rule was entered into the agenda (activated).
If that is true, I cannot figure out why we’re experiencing this.
As our number of rules increases, we’re seeing exponential increases in repetitive activation/deactivation pairs, even on rules where we know the data does not match the conditions.
 
Example:
The following rule (abbreviated here) creates an object of type PolicySet if there are none that match the conditions.
I would expect this rule to activate once, then fire, wherein the matching PolicySet is created, and then never activate again since the absence of a matching PolicySet object is never again true.
However, in a rule base of ~4,000 rules, we see this rule activating 975 times and deactivating 975 times. This is just one example – nearly all our rules do this, and it is seriously impacting decisioning performance.
 
Have I misunderstood the meaning of “activation”? Can anyone help me understand this?
 
rule "RS6090.1.12_RF7007_50001012"
        when
                LendingProduct ( $exitStrategyType1 : exitStrategyType )
                Features ( $lienPriority1 : lienPriority )
                DecisionResultsInfo ( $dealRiskCategory1 : dealRiskCategory )
                TransactionDetail ( $parentTransactionDetail1Id : myId )
                not
                (
                        PolicySet ( $parentPolicySet_1_Id : myId, parentId == $parentTransactionDetail1Id )
                        and
                        PolicySetIdentifier ( parentId == $parentPolicySet_1_Id
,  lienPriority == $lienPriority1
                                , exitStrategyType == $exitStrategyType1
, dealRiskCategory == $dealRiskCategory1)
                )
        then
                // Content removed… rule creates the policy set and the policy set identifier, and initializes all appropriate elements
                // After doing so, why does it activate/deactivate 1800+ times in a rule base of 4000 rules?
                System.out.println("6090 fired.");
End
 
Thanks.
Tom Murphy
Business Process Consultant
Wells Fargo HCFG - CORE Deal Decisioning Platform
800 S. Jordan Creek Parkway | West Des Moines, IA 50266
MAC: X2301-01B
Office: 515 324 4853 | Mobile: 941 320 8014
This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation.
 
 
 

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users