> 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] --------------------------------------------------------------------
