[rules-users] What if Rules change frequently...

[Edson Tirelli]

   Great advice Michael. Thanks for sharing.

   James,

   I thought your case was a bit more complex where some rules change 
but others not and at the same time you have a statefull long running 
working memory. In a situation like that, drools 3 allows you to 
add/remore rules "on-the-fly", automatically applying all facts already 
asserted in "live" working memories to the new rules.
   But for cases where you don't have this long running working memory, 
best to do is go the path Michael described. Creating working memories 
is cheap by design and will indeed provide the isolation you asked for.

   Unfortunatelly, keeping the reference to the correct (most recent) 
rulebase is something you will need to implement.

   Maybe we can add some features in the BRMS to help with that in the 
future.

   []s
   Edson


Michael Rhoden wrote:

>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 at lists.jboss.org
>[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of jdepaul
>Sent: Wednesday, January 31, 2007 3:18 PM
>To: rules-users at 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 at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>_______________________________________________
>rules-users mailing list
>rules-users at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>
>  
>


-- 
 Edson Tirelli
 Software Engineer - JBoss Rules Core Developer
 Office: +55 11 3124-6000
 Mobile: +55 11 9218-4151
 JBoss, a division of Red Hat @ www.jboss.com