I am not a JESS user at the moment but have a definate need for a rules engine that runs in a multi-threaded Java environmen and so have been monitoring jess-users for a while now. Over the past year I've developed a framework/methodology that addresses both the description and implementation of multi-threaded systems in Java. The description of this work is at www.object-forge.com and although I don't totally understand the nuances of this discussion it seems to me that some of this work might have an application here. In particular it provides a robust, reliable way to control thread access to shared resources; this seems to be what is going on here. If someone with more knowledge of JESS could look at the site and offer some feedback I'd be interested in integrating this work with JESS. This is clearly self-serving since I need to do this in the near furture anyway but some insight into the issues involved would be great help due to the fact that I am a JESS novice.
Thanx, Allan Clearwaters The Object Forge www.object-forge.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alan Moore Sent: Thursday, September 04, 2003 6:42 PM To: '[EMAIL PROTECTED]' Subject: RE: JESS: Defrule ordering woes > My only concern is whether to expose the complexity to the user. On > the one hand, control is good; on the other hand, hard-to-understand > features don't get used. Here, I'm tempted to simply make the entire > RHS of every rule "atomic" in this sense, w.r.t. the agenda, because, > consider this: no other rules can fire, anyway, while a rule is > firing; the atomicity will -only- affect performance, not any > observable behavior. This works for threads running rules and asserting/definstancing on the RHS. If a thread that isn't firing a rule does multiple asserts or definstances then it won't benefit from the RHS agenda locking. One way to work around this is to: 1) Create a single object to contain all the data elements that need to be placed into working memory. 2) Definstance that object in the context of the non-rule-firing thread. 3) Let a rule, running on the runUntilHalt() thread, do the asserts or definstances of the various data elements as required. This way, all mods to working memory and all rule firing is done by the runUntilHalt() thread - except, of course, for the definstance in step 2. This data element holding object is, in effect, a transaction object usually with a name like MyXYZRequest or My123Event. I've employed this pattern repeatedly and it works like a charm. Throw in a FutureResult for good measure and you've got a fast, reliable, thread-safe system. alan -------------------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
