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
