You only really need to call (reset) once, at the very beginning,
before (run) is ever called (some rules won't work right if (reset)
has never been called at all.) Otherwise, you only need to call it if
you want to (for instance, to clear the fact-base, all the
activations, reset global variables, etc, etc, etc.) If you don't want
to reinitialize everything, there's no need to ever call (reset)
again.
Note that a given rule will only fire on a given set of facts once. If
you want the rule to fire given the same set of facts again, the facts
have to be retracted and reasserted, as happens during a (reset) in
the presence of (deffacts.) This is why the examples that ship with
Jess call (reset) then (run), then (reset) again, etc. for benchmarks.
I think Bijal Modi wrote:
>
> Hello,
>
> I have following simple design.
>
> I have a rulebase rb.clp. My java program (modified copy of jess.Main)
> reads the file and loads all the rules and facts in an instance of Rule
> Engine (jess.Rete). When a client calls with some data, these data are
> asserted as facts and Rule Engine 'runs' corresponding rules that
> it finds for those facts and retracts those facts. Client then 'fetches'
> the result through Java API.
>
> When another call comes, since none of the pre-existing facts were
> altered, no '(reset)' is called and the new facts are asserted and
> process continues. I keep the rule engine running by having some facts
> always getting asserted and some rule which does nothing but sleeps (as
> in Jess
> FAQ) getting fired at fixed intervals.
>
> Is this a typical of a Java application design that uses Jess for rule
> evaluation? In some of the examples I read, reset was being called. But
> wouldn't that necessiate reloading all the facts, and global variables
> everytime? (of course, it makes sense if they change during a rule
> evaluation). Would calling a 'mini-reset' that just resets only the
> facts and global-variables that has changed be more efficient? Do I have
> to retract these facts every time in the action part of the rule? Any
> pointers for memory/speed optimization similar designs would be highly
> appreciated.
>
> Thanks for your help,
>
> -Bijal Modi
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9214 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
