Edson,
Thanks for the quick reply.
I'll go for the approach #1. I am also thinking of using Stateless sessions rather
than Stateful to basically always ensure that the engine does one full run over a static
set of rules. I am not going to maintain long-running sessions at all.
One small question: when I create a StatelessSession from the rulebase, will it also
maintain a reference to the rulebase? In which case, when the session is done, is it going
to release the reference? I'm trying to see if I am going to have some dangling
references to old rulebases (R1) laying around even after the ruleBase variable in the
singleton class points to the new R2 rulebase instance already. Just to make sure that old
references are GC-ed properly, since, as I understand, rulebases are pretty big objects.
Thanks,
Marina
----- Original Message ----
From: Edson Tirelli <tirelli(a)post.com>
To: Rules Users List <rules-users(a)lists.jboss.org>
Sent: Wednesday, August 20, 2008 1:55:15 PM
Subject: Re: [rules-users] strategy for rulebase updates in a cluster?
Marina,
Operations over an existing rulebase (add/remove rules/packages) will lock existing
stateful sessions in order to be executed making them thread safe. But having said that,
for a JEE environment I would design it as in scenario #1.
I.e., requests are arriving and being handled by sessions created against a rulebase
R1. When an update is made, the application will simply create a new rulebase (R2) and
your singleton will now reference R2. Working memories have an internal reference to the
rulebase used to create them, so existing sessions will work with the old rulebase until
disposed, but any new request will create sessions against R2 (since your singleton now
holds a reference for R2).
I like this solution because it provides, IMO, the safest and more consistent way of
handling existing sessions, since you ensure a complete reasoning cycle (session) is made
with an immutable set of rules, that can be easily tracked by whatever audit mechanisms
you use. Only new requests will use the new rulebase, and are ensured to also complete the
reasoning with immutable rules.
If you have long running sessions, though, the problem is a bit different and there is
no other option IMO, except using solution #2.
Hope it helps,
Edson
2008/8/20 Marina <ppine7(a)yahoo.com>
Hello,
I'm integrating DRools into a J2EE application and need to understand how it behaves
in a multi-threaded distributed environment. I have many questions about thread safety but
for now I'll ask about clustering only and post other questions separately.
So, as I understand, Drools per se is not cluster-aware. In my current design I have a
singleton class, RuleEngineMAnager, that holds a reference to a RuleBase. Hence, there
will be one instance of a rulebase per JVM per machine in a cluster. Rules can be
added/modified from any node in the cluster, and the modifications have to me made visible
in all rulebases.
The way I handle it now is by using a DB as the shared unit and setting up a flag when
modifications are made in any JVM. Next time a request comes in for the rule engine to run
all rule , the flag is checked and the RuleBase is updated.
So, my question is about how to handle the rulebase updates most efficiently.
I see two possibilities:
1. ditch the rulebase completely, build a new Package of rules , create a new rulebase and
add the package to it
2. Use the same rulebase - just remove the old package of rules and load in the new one.
The issues here are:
-- what if there are operations going on in the rule engine, invoked from other threads,
at the time I want to do either 1 or 2?
Say, in the scenario #2, the rule engine is running all rules in one thread. At the same
time I'm asking it to drop the rule package from another thread and add the new one.
Is it going to finish running all rules with the old package, return results, and only
then do the update of the package?
And in the scenario #1, if the rule engine is running the rules, and I try to destroy the
old rule base - are those operations sequential?
Any suggestions as to how to design this functionality in the most efficient and safe
way?
thank you!
Marina Popova
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @
www.jboss.com