Another solution would be to have a simple rule matching an Object
that is a container of facts:
rule "synced bunch insert"
when
$fc : FactContainer( $facts : facts )
then
for( Object $f : $facts ){ insert( $f ); }
retract( $fc );
end
Threads just insert a FactContainer; so this is synced in all ways.
BTW: Having a session run continuously in a thread of its own may be a
necessity if there are timers active; thus just using fireAllRules may
not be a solution in all situations.
-W
On 6 October 2010 10:15, Swindells, Thomas <[email protected]> wrote:
> I'd suggest that it may be simple to have a (synchronized) helper method
> which you call to insert your objects.
> This method would create a batch command containing an insert command and a
> fireAllRules command. You only need to fire the rules after you have changed
> something and this approach removes all multithread access into the working
> memory.
>
> Thomas
>
>> -----Original Message-----
>> From: [email protected] [mailto:rules-users-
>> [email protected]] On Behalf Of Edson Tirelli
>> Sent: 06 October 2010 01:28
>> To: Rules Users List
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>>
>> Norman,
>>
>> What you say makes sense, but it is not implemented. It is
>> something I think would be good to have. May I suggest you open a JIRA
>> for it so we track it?
>>
>> Meanwhile, the workaround I suggest is that instead of using
>> fireUntilHalt(), you call fireAllRules() in a loop, either after each
>> X insertions of every Y seconds, depending on your system's
>> architecture.
>>
>> Edson
>>
>>
>> 2010/10/5 Norman C <[email protected]>:
>> >
>> > Thanks for the suggestions. They all look like good ways to handle the
>> > situation I described. However, they require modifying all of the rules to
>> > check for the latch object and its state, which I would prefer not to do
>> > and
>> > doesn't seem like would be necessary.
>> >
>> > It seems to me that this is something that Drools can handle internally
>> > without the rules having to be written this way. Since the rules engine
>> > processes rules in a single thread, it's a concurrency issue.
>> > fireUntilHalt
>> > should be blocked when a fact is inserted/updated/retracted, until all
>> > activations as a result of that change in working memory are completed.
>> >
>> > Thoughts?
>> >
>> >
>> >
>> > Norman
>> >
>> > ________________________________
>> > From: Wolfgang Laun <[email protected]>
>> > To: Rules Users List <[email protected]>
>> > Sent: Sun, October 3, 2010 10:51:08 PM
>> > Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> >
>> > 2010/10/4 Greg Barton <[email protected]>
>> >>
>> >> 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 <[email protected]> wrote:
>> >>
>> >> From: Wolfgang Laun <[email protected]>
>> >> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> >> To: "Rules Users List" <[email protected]>
>> >> 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 <[email protected]>
>> >>
>> >> 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 <[email protected]> wrote:
>> >>
>> >>
>> >>
>> >> > From: Norman C <[email protected]>
>> >>
>> >> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>> >>
>> >> > To: [email protected]
>> >>
>> >> > 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
>> >>
>> >> > [email protected]
>> >>
>> >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >>
>> >> rules-users mailing list
>> >>
>> >> [email protected]
>> >>
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -----Inline Attachment Follows-----
>> >>
>> >> _______________________________________________
>> >> rules-users mailing list
>> >> [email protected]
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> rules-users mailing list
>> >> [email protected]
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > [email protected]
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> >
>>
>>
>>
>> --
>> Edson Tirelli
>> JBoss Drools Core Development
>> JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-users mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you have
> received this message in error, please immediately notify the
> [email protected] and delete it from your system as well as any copies. The
> content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes. To protect the environment please do not
> print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
> 4EX, United Kingdom. A company registered in England and Wales. Registered
> no. 3080780. VAT no. GB 603 8808 40-00
> **************************************************************************************
>
> _______________________________________________
> rules-users mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
