[rules-dev] Concurrent Behavior of Firing Rules and Queries

Fenderbosch, Eric Eric.Fenderbosch at fedex.com
Fri Jan 25 10:52:31 EST 2008


I asked some of these questions in IRC and tirelli asked me to post here
in the dev list.
 
We are hoping that drools will have this functionality sometime in the
future.  Our target production date is May.  These questions are related
to the Job/Workers problem that Steve Shabino has discussed with the dev
team before.
 
Start w/ steady state.  Facts loaded and rules fired.  We have truth as
of time1.
Thread 1 asserts new/updated facts and calls fireAllRules.  fireAllRules
takes about 20 seconds to run.
Thread 2 calls getQueryResults before fireAllRules completes.  The
returned QueryResults should be correct and consistent with truth as of
time1.  Call to getQueryResults should NOT block until fireAllRules
completes.
Thread 1 call to fireAllRules finishes.  We now have truth as of time2.
 
<tirelli> just as a quick comment: from our perspective, the support to
concurrent query calls would return a consistent state, but not exactly
what you called truth at time1
<tirelli> since the engine would be firing rules all the time
 
We do have a workaround if our desired behavior isn't "correct."  The
queries we'll need to run are well defined and a relatively small
number.  Speaking in the Job/Worker realm, we'll need to query for the
TopWorkers for all Jobs.  We could keep a map of Job to TopWorkers and
update the map every time fireAllRules completes and service all
TopWorker by Job queries from this cache.
 
Maybe the bigger question, but maybe not appropriate for the dev list,
is our concern about query results possibly changing while fireAllRules
runs valid?  Our concern is that we could get different results
depending on when we perform the query.  For example, if we query for
TopWorkers for a Job against "truth @ time1" and "truth @ time2" our
results should be well defined.  However if we perform the same query
while fireAllRules is running we might get results that are different
from both those other results.  Is this a valid concern?
 
Thanks for your time.
 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080125/09d067f2/attachment.html 


More information about the rules-dev mailing list