On Wed, 16 Aug 2000, Thomas Barnekow wrote:
> > 1. can the same rete engine process requests from multiple threads
> > simultaneously or should I create a Rete engine pool?
>
> You need to differentiate between
> (1) asserting facts
> (2) running the engine using Rete.run() or Rete.runUntilHalt()
>
> Facts can be asserted by multiple concurrent threads. On the other
> hand, only a single thread can run the engine and execute the rules'
> RHSs. This is equal to a single thread fetching tasks from a work queue
> and executing them sequentially.
Does this single thread block or does it fully utilize the CPU? I mean,
if a rule involves a request to an external web/database server, does the
thread simply wait for the request to return or process other rules while
waiting? What happens if a particular LHS takes a really long time to
return (involves a big database query)?
Even if the thread doesn't get blocked, it seems like you should be able
to have multiple threads/processors running in parallel on the same
context (otherwise you get sub-optimal performance on multi-processor
CPUs).
> If you want to actually process requests in parallel then you'll need
> an engine pool. Otherwise, you'd need to explicitly structure your rules
> in a way that leverages the inherent parallelism.
What does it mean to leverage the inherent parallelism? If two different
threads assert a request into the same running Rete object, what happens?
> > 2. what is the best way to pass an HttpServletRequest into Jess?
>
> You were talking about a business logic servlet. Why does it need to
> know anything about HTTP requests? I'd rather hide that in some
> interface that translates the requests in a form most suitable for
> processing by business rules.
I agree that was why I gave a proposed template in the last mail.
My feeling is that I don't know enough to get very clever about
HttpServletRequest abstraction. If I can get the basic request object
into the Jess in a reasonable format, I will evolve transformation rules
that I can optimize out into linear java code later.
The big question here is: Do I want to process Java Hashtable in the LHS
of the rules? is there a better way of passing name-value pairs into
jess?
> > 3. how do I clean up after processing a request (so I don't accumulate a
> > large number of obsolete request facts)?
>
> You can usually retract request and control facts right after you've
> "used" them. You can also proceed in a sequence of phases, the last one
> being the "cleanup phase". Somebody posted a set of rules to the list,
> that provide a framework for phase control.
I looked up phase control and did not see much. Can you give a more
direct reference? Is there a way a RHS can get a list of all facts used
to fire it? Then you could accumulate a list of facts to dump.
> > 4. is this a good idea at all?
>
> I'd say it's a very good idea. I did a similar thing for systems
> integration. You should work towards a clear-cut separation between
> business logic and the more technical stuff.
Do you have any code that would be useful here?
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-212-420-7700 voice The Easiest Way To Shop (sm)
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
