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 [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 [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to