Sure, you would have all kinds of problems with a design like this;
it's a bad idea. Get rid of the Dispatcher rule, write the individual
rules like this:
(defrule ModuleA::RulesA
(declare (auto-focus TRUE))
?context <- (MAIN::FactX(OBJECT ?contextObject) (env ModuleA))
...
Two things are happening. First, since Jess has the auto-focus
feature, why not use it? You're just slowing things down by using a
rule to do the same work. Second, as you originally wrote them,
RulesA and RulesB both matched exactly the same facts; you need to
write them so that they match only the facts you want processed by
the given module. This last change very easily eliminates the whole
problem you're concerned about.
On Jul 4, 2007, at 9:55 PM, folderman wrote:
Thank you very much for the quick response first of all.
Actually, I'm not using the "auto-focus" keyword, instead I would
focus a
specific module in my code based on the incoming fact.
Suppose I have rules on a Fact (typed "FactX") in both ModuleA and
ModuleB,
i.e.
(deftemplate MAIN::FactX
(declare (from-class test.FactX)
(slot-specific TRUE)))
(defrule MAIN::Dispatcher
"Dispatcher"
?context <- (MAIN::FactX(OBJECT ?contextObject) (env ?env1))
=>
(focus ?env1))
(defrule ModuleA::RulesA
"Dispatcher"
?context <- (MAIN::FactX(OBJECT ?contextObject) (env ?env1))
=>
(print "running in moduleA"))
(defrule ModuleB::RulesB
"Dispatcher"
?context <- (MAIN::FactX(OBJECT ?contextObject) (env ?env1))
=>
(print "running in moduleB"))
So my concern would be that, would there be chances for a FactX
with the
"env" attribute = "ModuleB", would get running in ModuleA, when it is
asserted into the rule engine while there is another fact already
running in
ModuleA and thus the current focus "ModuleA" during the assert time?
What's more is that there might be more than 1 rules in the
modules, and
would the fact triggering the rules in the other module during
execution?
Thank you very much!!
Best Regards,
folderman
Ernest Friedman-Hill wrote:
If a rule is declared as "auto-focus", then when it is activated, it
will change the focus module to its own module. But in the absence of
this declaration, an activated rule in a non-focused module will just
sit and wait for its module to be focused again; it will not fire
immediately,
On Jul 3, 2007, at 11:26 PM, folderman wrote:
Hi everyone,
I'm currently integrating JESS into my web application and the
architecture
is typical; running rete.runUntilHalt() and asserting a shadow fact
for an
incoming HTTP request. But as more and more rules are developed, I'm
thinking to partition the rules into modules.
Now, suppose I have 2 module, moduleA and moduleB, and some rules
are
defined to match the same set of shadow facts on the LHS. In
essence, I
could "switch" the execution logic by either focusing moduleA or
moduleB,
and the decision for which module gaining control is depends on the
screen
the user is in.
However, there is an incoming the fact which should be running in
moduleB
but there might be chances that rule engine is processing another
requests
and moduleA is the current focus; if the incoming fact is assert at
that
time, it might be running moduleA instead of moduleB.
So, might I confirm if the above scenario would happen? Is there any
workarounds to avoid the unnatural execution? What would be the
orthodox way
to implement the module control flow then? Any help or opinion
would be
appreciated.
Thank you very much, everybody!!
Best Regards,
folderman
--
View this message in context: http://www.nabble.com/Module-and-
Concurrency-tf4022222.html#a11424331
Sent from the Jess mailing list archive at Nabble.com.
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users
[EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Advanced Software Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users
[EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
--
View this message in context: http://www.nabble.com/Module-and-
Concurrency-tf4022222.html#a11439857
Sent from the Jess mailing list archive at Nabble.com.
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users
[EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Advanced Software Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
