[rules-users] strategy for rulebase updates in a cluster?

[Edson Tirelli]

   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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080820/11ddf704/attachment.html