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
When we call the engine amongst the data we will use to setup the situation
WorkingMemory wmPrice = priceBase.newWorkingMemory();
FactHandle fhPrice = wmPrice.assertObject(xyz);
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.
[mailto:email@example.com] On Behalf Of jdepaul
Sent: Wednesday, January 31, 2007 3:18 PM
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
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:
Sent from the drools - user mailing list archive at Nabble.com
rules-users mailing list