12:51 a.m.
2010/10/4 Greg Barton <greg_barton(a)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(a)gmail.com> wrote:
From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
To: "Rules Users List" <rules-users(a)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(a)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(a)yahoo.com> wrote:
> From: Norman C <rent_my_time(a)yahoo.com>
> Subject: [rules-users] fireUntilHalt and timing of rule activations
> To: rules-users(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----Inline Attachment Follows-----
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users