I think Alan Moore wrote:

> Could you selectively lock the agenda on a per-assert basis by having the
> thread asserting facts be able to run a "transaction" during which the
> agenda is locked?
> 
> This could be done explicitly like this:
> 
> (defrule abc
> ...
> =>
>    ((engine) startTransaction)
>    (assert (123))
>    (assert (456))
>    ((engine) endTransaction)
> )
> 
> or like this:
> 
> (defrule abc
> ...
> =>
>    (transaction
>       (assert (123))
>       (assert (456))
>    rollback
>       (...)
>    )
> )
> 

This is an interesting point. I've been thinking about it, and I've
decided that the current behavior is wrong; asserting a single fact
should be atomic w.r.t the agenda. But multiple facts, this is
definitely an interesting point. Your suggestion could save some
computational effort; if asserting (123) above activated a bunch of
rules, but (456) deactivated them, then you'd save a lot of work if
you didn't have to add all those activations to the agenda, then
remove them... this is really a very good idea.

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.

> 
> BTW - there isn't an Rete#assertFacts(Fact[] facts, Context context ) method
> to mirror the existing behavior of (assert).

Indeed, but all (assert) does is call the Java method in a loop.

> 
> I know I'm referring to multiple facts being asserted but I think the
> problem of "salience/agenda inversion" for a single fact can be generalized
> to more than one fact.

Yes, this is an excellent point, well worth considering.

> 
> The granularity allowed here is similar to field/record/table/database level
> locking in databases. FWIW, an interesting high-concurrency approach found
> in PostgreSQL is described here:
> 
> http://www.linuxgazette.com/issue68/mitchell.html
> 
> My 2cts worth.

2 cents would be the steal of the century. Your ideas are always welcome.

> 
> alan


---------------------------------------------------------
Ernest Friedman-Hill  
Distributed Systems Research        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]
--------------------------------------------------------------------

Reply via email to