... you need to be aware that such activations will be created even if it was already fired for the old rule...

We have done what I believe you are describing. Running under tomcat we load our rules at server load. So in the contextloader we create several RuleBase instances (just one for each different type of rule base we need). We store our rules in a database initally, so loading involves pulling all rules by date/status. This is something we had to create outside drools/jboss. Having that date allows multiple rules to be loaded and only span certain areas of time with no overlap. So if a rule that adds/subtracts to a price, for instance were $1.00 from say Jan 1 12:00am - Jan 31 4:04pm and now there is a new rule that is $1.25 it should begin Jan 31 4:04pm. This way both rules are in the rulebase at once. Since we build the rules dynamically it was as simple as adding a new condition to each rule that described the date the rule should fire. As far as loading... Setup your rulebase from your DRL or various datasource, then context.setAttribute("pricingRuleBase",ruleBase); When we call the engine amongst the data we will use to setup the situation we pass.. priceBase = (RuleBase)this.getServletContext().getAttribute("pricingRuleBase") And then.. WorkingMemory wmPrice = priceBase.newWorkingMemory(); FactHandle fhPrice = wmPrice.assertObject(xyz); retePrice.fireAllRules( ); fhPrice.doSomethingWithResults(); When we need to reload based on whatever situation, error or emergency change etc you simply (click a form) to call a similar method to load the new rulebase in question locally and set it to the context. This overrides your "pointer" for the next call to the engine. To make sure this happens smoothly we pad all our dates on rules 15 minutes, so our deploy procedure "deploys" rules with the current time (or whatever you request) plus 15 minutes. It then calls a reload on the system, so in fact the new rules will show in about 15 minutes time. You really don't need this but for our application it made business users feel better. We are using drools 2.x so things are a little better now, but for ~4k rules we translate in about 30 seconds to a DRL, and then load that DRL in about 30 seconds, so a change could happen with-in a few minutes in reality. If it needs to be faster than that I would take Edson's advice and assert new facts versus loading the whole rulebase again. You would still have to engineer some date check into your rule logic and possibly figure out a way to re-assert current rules firing with different dates so as to basically turn them off. BTW we have been using this method above for over a year with zero problems. Hope this helps. -Michael -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of jdepaul Sent: Wednesday, January 31, 2007 3:18 PM To: rules-users(a)lists.jboss.org Subject: Re: [rules-users] What if Rules change frequently... Edson Tirelli-3 wrote: >... you need to be aware that such activations will be created even if >it was already fired for the old rule... > > Edson - could you please expand your explanation a bit - would like to know a little better what you meant above. FYI - my goal is to assert each new Fact against the latest set of Rules with minimum latency when rules change. I would like to assert each Event/Fact individually (not in an on-going conversation). I want each assertion to result in exactly ONE or ZERO matches to the current set of rules in place and act on it only if Match occurs. I envision having a component that holds Drools' RuleBase object as a Singleton with current set of rules retrieved from the DataBase at application initialization - the Singleton, would be used by multiple threads in the ApplicationServer for each request. Each thread would get a RuleBase reference from the Singleton and create newWorkingMemory() EVERY time, assert the Fact and FireAllRules and then be all done until the next Event arrived... By creating newWorkingMemory() every time for each Fact, I'm hoping to achieve "isolation" of events - that is preventing multiple rules being activated and firing. When rules change, I'm hoping for some mechanism (JBoss or custom) to update the RuleBase and its packages. Is this achievable using dynamic rules with JBoss? Please comment - -- View this message in context: http://www.nabble.com/What-if-Rules-change-frequently...-tf3149726.html#a873 7858 Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users