[rules-users] fireUntilHalt and timing of rule activations

[Wolfgang Laun]

2010/10/4 Greg Barton <greg_barton at yahoo.com>

> If you don't have some way of associating the data with a particular Latch
> it's easy to get overlap when processing datasets.  In general you need some
> way to group the data together.  You can avoid a back reference to the Latch
> by having a Set of some sort in the Latch to which you add all data in the
> batch.


Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.


>  If you use a Set backed by an IdentityHashMap the overhead is pretty
> small, and rules look like this:
>
> rule "CountAs"
>        dialect "java"
>        salience -1
>        when
>                l : Latch()
>                 a : A( this memberOf l.dataSet )
>         then
>                retract(a);
>                l.incACount();
>                 System.out.println("Found an A in " + l);
> end
>
> See attached project.
>
> THough I like the cleverness of using the "data in matched objects alters
> rule properties" trick, you could have just as easily had a "Latch(value ==
> true)" conditional, and that would be more clear,


It was meant to emphasize the role of Latch.value as an enabler for the rule
in contrast to a regular constraint being part of the application logic.
YMMV ;-)



> IMO.  I'm curious to see of the enabled trick would perform better, though.
>

Whichever way, there is a considerable burden associated with writing the
rules and, possibly, inserts and retracts. I wonder what the benefits of
having the session run all the time are as opposed to simply let it fire
until it stops; then do the inserts and then fireUntilHalt again? If there
is, I'd opt for the addition of an atomic insertAll(Object... objects) and
then none of this hocus-pocus would be necessary.

-W


>
> GreG
>
> --- On Sun, 10/3/10, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>
> From: Wolfgang Laun <wolfgang.laun at gmail.com>
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> To: "Rules Users List" <rules-users at lists.jboss.org>
> Date: Sunday, October 3, 2010, 4:23 AM
>
> There is another way of associating a Latch object with rules, without
> having to store a reference to a Latch in objects:
>
> rule "CountAs"
> enabled ( $v )
> when
>      Latch( $v : value )
>      X( ... )
>
> then ... end
>
> At the beginning, insert Latch( false ), which blocks all rules with this
> construction, or modify the Latch object to false before inserting more
> facts. Then, insert the facts, and, at the end, modify Latch to true.
>
>
>     Latch latch = new Latch( true );
>     FactHandle fh = kSession.insert( latch );
>     kSession.fireAllRules();
>     latch.setValue( false );
>     kSession.update( fh, latch );
>
> Of course, you can use multiple Latch objects, adding a name field with a
> specific value, so that a latch applies to a subset of rules only:
>
>
> rule "CountAs"
>
> enabled ( $v )
>
> when
>
>      Latch( name == "CountAs", $v : value )
>      ...
>
> But be aware that changes to Latch objects will retrigger rules that have
> fired previously; so with this approach you'll have to make sure to retract
> facts when they have been processed.
>
>
> -W
>
>
> 2010/10/3 Greg Barton <greg_barton at yahoo.com>
>
> Nope, you're not missing anything.  What you need is a control object of
> some sort thst's inserted after all of the "real" data is inserted. (See
> attached project for an example.) Rules will look like this, if the control
> object is called BatchLatch and data objects A:
>
>
>
>
> rule "CountAs"
>
>         dialect "java"
>
>         salience -1
>
>         when
>
>                 l : Latch()
>
>                 a : A( latch == l )
>
>         then
>
>                 retract(a);
>
>                 l.incACount();
>
>                 System.out.println("Found an A in " + bl);
>
> end
>
>
>
> Note that the A object being processed is tied back to the latch.  This is
> so multiple latches can be processed simultaneously and their processing
> won't be intermingled.  This is necessary because there's no guarantee that
> two Latch objects aren't in working memory at once. (Though you could create
> a rule that enforces this.)
>
>
>
>
> GreG
>
>
>
> --- On Sat, 10/2/10, Norman C <rent_my_time at yahoo.com> wrote:
>
>
>
> > From: Norman C <rent_my_time at yahoo.com>
>
> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>
> > To: rules-users at lists.jboss.org
>
> > Date: Saturday, October 2, 2010, 10:22 AM
>
> > Hi All,
>
> >
>
> > In my app, I have a separate thread calling fireUntilHalt()
>
> > continuously.  I
>
> > have quite a few rules, and I am using salience extensively
>
> > to control the order
>
> >
>
> > in which rules are executed.  What I have seen (by adding
>
> > an event listener) is
>
> > that as a new fact is inserted, various rules are
>
> > activated.  Often, the
>
> > fireUntilHalt will start executing fireNextItem in
>
> > DefaultAgenda before all of
>
> > the activations are complete.  So if the rule with the
>
> > highest salience
>
> > value hasn't been activated at this point, then the first
>
> > rule to be fired isn't
>
> >
>
> > the correct one.
>
> >
>
> > This can be worked around by waiting for insert to return
>
> > and then calling
>
> > fireAllRules().  But it seems like the session should
>
> > block fireUntilHalt from
>
> > trying to execute activated rules until all activations are
>
> > complete.  Or am I
>
> > missing something here?
>
> >
>
> > thanks,
>
> > Norman
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > rules-users mailing list
>
> > rules-users at lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
> >
>
>
>
>
>
>
> _______________________________________________
>
> rules-users mailing list
>
> rules-users at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20101004/0680607f/attachment.html