Thanks for the feedback. Wolfgang, that's a good thought, but we do need to do some re-evaluation along the way - just not as much as we're doing right now - so the 'dirty update' approach doesn't seem applicable here.
Robert, your post got me thinking. If I'm interpreting what you're saying correctly - Drools is smart enough to know which rules depend on which types of objects in their LHS, so if you modify an object of a particular type, only the rules that depend on that type get re-evaluated. It seems completely logical, but I hadn't thought about it that way. Am I understanding the mechanics correctly? If so, I think we need to re-design our 'output' fact a bit. It currently contains several lists of codes - 2 lists for the order, 1 for the buyer, and 1 for each of the recipients. It's bound to a variable in the LHS of nearly every rule and is updated in the RHS of a majority of them, which I now realize is causing nearly every rule to be re-evaluated after the firing of a majority of the rules. As a result, performance deteriorates rapidly as the number of facts grows. I'm thinking that we should put the lists of suspect codes directly into the facts that they're related to so that when a list is updated, only the rules that care about that type of fact will get re-evaluated. We'd get rid of the 'output' fact altogether and instead, after the fireAllRules() call completes, we'd iterate through all of the facts we put into the rules engine and retrieve the lists of codes from each. How does this approach sound? -- View this message in context: http://drools.46999.n3.nabble.com/Preventing-re-evaluation-on-modification-of-output-fact-tp3455022p3497378.html Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users