[rules-users] RE: fact base storage?
Greg Barton
greg_barton at yahoo.com
Thu Oct 9 21:04:09 EDT 2008
Nope. See the StatefulSession.async* and StatelessSession.async* methods. They are threadsafe.
--- On Thu, 10/9/08, Evans, Jess <JEvans at collegeboard.org> wrote:
> From: Evans, Jess <JEvans at collegeboard.org>
> Subject: RE: [rules-users] RE: fact base storage?
> To: greg_barton at yahoo.com, "Rules Users List" <rules-users at lists.jboss.org>
> 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: rules-users-bounces at lists.jboss.org
> [mailto:rules-users-bounces at lists.jboss.org] 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
> <JEvans at collegeboard.org> wrote:
>
> > From: Evans, Jess <JEvans at collegeboard.org>
> > Subject: RE: [rules-users] RE: fact base storage?
> > To: "Rules Users List"
> <rules-users at lists.jboss.org>
> > 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: rules-users-bounces at lists.jboss.org
> > [mailto:rules-users-bounces at lists.jboss.org] 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: rules-users-bounces at lists.jboss.org
> > [mailto:rules-users-bounces at lists.jboss.org] On Behalf
> Of Evans, Jess
> > Sent: Thursday, October 09, 2008 11:54 PM
> > To: rules-users at lists.jboss.org
> > 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
> > 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
More information about the rules-users
mailing list