Nope. See the StatefulSession.async* and StatelessSession.async* methods. They are threadsafe.
--- On Thu, 10/9/08, Evans, Jess <[EMAIL PROTECTED]> wrote: > From: Evans, Jess <[EMAIL PROTECTED]> > Subject: RE: [rules-users] RE: fact base storage? > To: [EMAIL PROTECTED], "Rules Users List" <[email protected]> > Date: Thursday, October 9, 2008, 5:26 PM > Thanks. That's the plan. However, my assumption is > that even if the > data model and rules support partitioning that you still > need to > synchronize calls to working memory so that two threads > aren't invoking > insert, fire*, retract, etc. at the same time. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Greg Barton > Sent: Thursday, October 09, 2008 6:13 PM > To: Rules Users List > Subject: RE: [rules-users] RE: fact base storage? > > That model sounds quite reasonable. You may also find it > useful to > partition your rules by user by having them match on a User > object of > some kind and user state that matches up with each User. > > rule > when > $u : User(); > UserState(user == $u); > ImmutableFact1(...) > ImmutableFact2(...) > then > ... > end > > That way you could have multiple users being processed > concurrently and > they wouldn't overlap. > > --- On Thu, 10/9/08, Evans, Jess > <[EMAIL PROTECTED]> wrote: > > > From: Evans, Jess <[EMAIL PROTECTED]> > > Subject: RE: [rules-users] RE: fact base storage? > > To: "Rules Users List" > <[email protected]> > > Date: Thursday, October 9, 2008, 4:32 PM Thanks for > the confirmation. > > > I think it should be straightforward to implement a > parser as you > > suggest to populate a list of java beans and assert > them to the > > working memory. I'm just surprised that this > doesn't already exist. > > > > May I ask how you manage the working memory? It looks > like you can't > > clone or snapshot a working memory. So, you must > either assert all > > the default facts in a new working memory for every > user > > session/request or use a shared synchronized working > memory. I'm > > building a web based wizard calculator with around 10k > default > > immutable facts. > > It's taking > > almost 800ms to assert and fire to reach an initial > state, so I'm > > planning on sharing one synchronized session. Is this > a reasonable > > approach or am I off my rocker? > > > > Cheers, > > > > -Jess > > > > ________________________________ > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > Of Vikrant > > Yagnick > > Sent: Thursday, October 09, 2008 2:45 PM > > To: Rules Users List > > Subject: [rules-users] RE: fact base storage? > > > > > > > > Hi Jess, > > > > > > > > I am facing the same problem right now. While, I do > not know of any > > OOTB ways to do this, I initially implemented an all > rule solution. > > > > In my case, I had a lookup table that based on a age > or gender got a > > rate or some value. > > > > > > > > Using some Excel Trickery, I got the 2 dimensional > table into one > > dimensional columns of the type: > > > > Age Gender Value > > > > Age and Gender became conditions and Value became the > Action. > > > > > > > > In your case, you could form a column with a dummy > LHS(1=1) and keep > > all the columns as Action Columns. > > > > In each Action Column you could build up your Fact. > > > > > > > > For Example you could do the following: > > > > > > > > Fact{ int a; int b; > > > > } > > > > Condition Action > > Action > > > > F: Fact > > > > f.set($1); > > > f.set($1) > > > > Eval(true) Col A > > > Col B > > > > Dummy Value <values for a> > > <values for b> > > > > > > > > If you generate a rule base out of this, it should > load your tables > > straight as facts. > > > > > > > > However, do note, that I did some rather Q&D > benchmarks for this and > > soon realized that the rulebase size and memory usage > was getting > > really large. (Especially the PermGen Size). > > > > > > > > You may want to have a look at the memory usage, in > case you need to > > load a large number of tables. Due, to the above(and > other reasons), I > > > just wrote a custom parser using JXL (The same Excel > Library Drools > > uses for Parsing Excels). It is really neat and would > make a simple > > solution. > > > > > > > > > > > > In, case you get another solution do post it to the > list. > > > > > > > > Cheers, > > > > Vikrant > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > Of Evans, Jess > > Sent: Thursday, October 09, 2008 11:54 PM > > To: [email protected] > > Subject: [rules-users] fact base storage? > > > > > > > > I'm trying to come up to speed on the drools > capabilities. I see that > > > drools supports loading rules from a decision table in > a spreadsheet. > > > I have a set of conversion tables that I'd like to > represent as facts > > asserted when the rule base has been loaded, but > before processing > > user requests. I could always model lookup tables in > a database, but > > I'd rather not have to build the CRUD interface to > manage them. > > I'd rather > > represent them so that each row in a spreadsheet > represents a fact > > (based upon a predefined java bean). Of course, I > could custom > > implement this functionality. However, I was > wondering if drools > > supports some OOTB means of loading facts from Excel > or other > > resource? > > > > > > > > thanks, > > > > > > > > -Jess > > > > > > > > > > > > > > > > > > > > > > MASTEK LTD. > > Mastek is in NASSCOM's 'India Top 20' > Software Service Exporters List. > > In the US, we're called MAJESCOMASTEK > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Opinions expressed in this e-mail are those of the > individual and not > > that of Mastek Limited, unless specifically indicated > to that effect. > > Mastek Limited does not accept any responsibility or > liability for it. > > This e-mail and attachments (if any) transmitted with > it are > > confidential and/or privileged and solely for the use > of the intended > > person or entity to which it is addressed. Any review, > > > re-transmission, dissemination or other use of or > taking of any action > > > in reliance upon this information by persons or > entities other than > > the intended recipient is prohibited. This e-mail and > its attachments > > have been scanned for the presence of computer > viruses. It is the > > responsibility of the recipient to run the virus check > on e-mails and > > attachments before opening them. If you have received > this e-mail in > > error, kindly delete this e-mail from desktop and > server. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > _______________________________________________ > > 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
