I think Jin Lian wrote: > > How would a singleton Jess engine do in a multi-threaded environment, such > as in a Web container. In this environment, each incoming request is being > served by a thread allocated by the container.
Jess is used this way very often. We keep this kind of application in mind during Jess's development. > > If multiple threads are executing rules in the rule-base, would all these > requests be processed in parallel or sequentially? > First note that a rule engine is a Java object, and you can instantiate as many as you want; separate engines are completely independent. It's possible to have one engine per client, or one per each small group of clients, for example. Each individual rule engine has basically two mutexes: one for the working memory, and one for the execution engine. One execution thread can be firing rules, while other threads are adding/removing/modifying data in the working memory. Rules can be firing while working memory is being modified, but only one thread can be firing rules at a time, and only one thread can be modifying working memory at a time. There are broadly two different architectures you can use to use Jess in a Web container in which one engine services multiple clients. In one, each individual client thread manipulates the working memory, then calls run() to fire the rules. This is fine if rule execution time is expected to be short; it depends on the application, but often this is adequate. The other way is to have a single thread dedicated to running the engine non-stop, while the individual client threads manipulate the working memory. In either case, the key to concurrent use is that each client-specific item in the working memory has to be identifiable as such -- i.e., if there's a ShoppingCart object, it needs to have a Client property, so many independent ShoppingCarts can exist simultaneously. > Where would evaluation results (both intermediary and final) be kept for > each thread? All the information Jess is working with is held in "working memory." There are some tricks you can do to use a database as a "backing store" so that data can be paged in as needed, giving you a sort of "virtual working memory". Many rule engines expect you to load working memory, run the rules, and then extract the contents of working memory to get an "answer." The Jess rule language gives you full access to all of Java, so in Jess, it's more typical to have rules that explicitly call a Java function to report a result. Instead of a load-run-extract cycle, you get more of a "continuous operation" pattern, which can be much more efficient. In the case of the Web container, it would be most natural if the Client or ShoppingCart objects (whatever form they take) included methods that the rules could call to report results. --------------------------------------------------------- Ernest Friedman-Hill Science and Engineering PSEs Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov -------------------------------------------------------------------- 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] --------------------------------------------------------------------
