[rules-users] rules-users Digest, Vol 53, Issue 62

Drools User drools2030 at gmail.com
Mon Apr 18 12:03:24 EDT 2011


Wolfgang, Thanks for the reply. The N threads means I need to be able to
query/check the list very often. The through put is undetermined, but could
be as high as several hundred lookups per second. It seems you agree that
using a stateful session would require me to process each request serially,
unless I wanted to spin up several copies of my facts. That would seem
inefficient.

Date: Mon, 18 Apr 2011 10:05:29 +0200
> From: Wolfgang Laun <wolfgang.laun at gmail.com>
> Subject: Re: [rules-users] Searching a list - Is Drools the answer?
> To: Rules Users List <rules-users at lists.jboss.org>
>
> It's possible that putting the "constants" into rules will result in a rule
> building process that's more complex than what you need to do if this data
> is in facts. Notice that your Object_1 has to participate in (at least)
> three different matching scenarios, which is a simple thing for a fact, but
> may need three rules if FirstName and LastName are literals in rules.
>
> A (serially) reusable Stateful Session would need to be set up with the 10k
> facts. A search request enters an object, produces results, and retracts
> the
> request; then the session is ready for the next request. (The N threads you
> are talking about results from some overall application context?)
>
> Regards
> Wolfgang
>
> 2011/4/18 Drools User <drools2030 at gmail.com>
>
> > I have been using Drools for several years, but just with constraints
> > (rules) on 1 set of objects at a time. Think many rules, few facts in a
> > stateless session. I have been given a new project at the office which
> > requires having about 10-100k facts and few rules. These 10k facts would
> be
> > basically constants, a list of things I need to search on each request. I
> > would then need to load a single object, based on a request to see if my
> > request object matched the list. It is somewhat a simple search, but I
> need
> > to be able to inject aliases and search partial matches in addition to
> exact
> > matches. A generic example:
> >
> > List:
> > Object 1 (FirstName=John, LastName=Smith)
> > Object 2 (FirstName=Will, LastName=Smith)
> > Object 3 (FirstName=Jon, LastName=Smith)
> >
> > Request/Use Case:
> > LastName=Smith, would return all 3 objects, but marked as single match
> > LastName=Smith, Firstname =John, Would return object 1, as exact double
> > match, and Object 3 a nickname double match
> > LastName=Smith, Firstname =J, Would return object 1 and 3, as partial
> match
> >
> > In the second request, I need to run all names through a nickname DB/list
> > to explode the name into multiple search patterns. Possibly using (
> > http://code.google.com/p/nickname-and-diminutive-names-lookup/)
> >
> > Hopefully that explains a bit about the problem.
> >
> > So to the question, there are a few ways to solve this. The simplest is
> > just SQL from a DB, but this proves to be slow to search all the ways I
> > need. I need sub second response times. An in memory DB is another
> possible
> > solution we are looking at. Not to think of Drools as the golden hammer,
> but
> > this smells like something I can use Drools for. My first thought was to
> > load the "List" as facts into a stateful session. My concern is wouldn't
> I
> > need N copies of the list loaded to have N threads? This would be
> > inefficient if so. I know rules aren't copied per working memory, but is
> > there a way to create a master working memory for facts to use?
> >
> > So my second thought is to convert my List into rules so they would only
> be
> > stored once in the system, regardless of number of threads using the
> engine.
> >
> > What do you guys think, am I on the right track with this? Is Drools a
> good
> > way to do this or is there something better I have overlooked?
> >
> > Thank you for taking the time.
> > -Drools user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110418/5409ad5c/attachment.html 


More information about the rules-users mailing list