[rules-users] Drools 5.3 partitioned rule base

[gboro54]

Agreed that I can have a rule to retract the order....i was just thinking if
the overhead of a reevaluation but can live with that...As far as the
threading...this logic is going to be deployed on a jboss instance using ejb
so I was thinking about, using the jboss thread pool...so when I say new
thread it may not, be new put, pulled from a pool....does that sound
reasonable?



laune wrote
> 
> Starting a new thread (if that's what you mean by process) for reusing
> an existing session to process another order is likely to create more
> overhead
> and it'll just make threads compete for this resources.
> 
> Multiple threads each dedicated to a single session object might be a
> better way to go.
> 
> I don't see any benefit to make simple order facts into events just for
> the
> sake
> of making them expire automatically. There ought to be a well defined
> state (or states) when processed orders are retracted by some rule.
> 
> -W
> 
> 
> On 3 March 2012 14:11, gboro54 <gboro54@> wrote:
> 
>> Mark,
>>
>>  I really appreciate the help and think I have come to a solution. Let me
>> know if this sounds reasonable.
>> 1. We will continue to use jBPM to coordinate the rules and business
>> logic
>> that need to occur in calculating charges for orders. However we will
>> work
>> the process to only work on a per order level.
>> 2. All orders are associated with accounts. We will keep one
>> knowledgebase
>> as the rule sets are the same and we will partition sessions by accounts.
>> The flow will go as follows:
>> a. If the session exists insert the order, start a new process instance
>> and
>> fire all rules
>> b. If the session has not been created: create the session, insert all
>> reference data that will be used by all orders in executions of the rule
>> set, insert the order, start a process, and fire all rules. This session
>> is
>> then cached(via a hashmap more then likely)
>> c. This process will be invoked asyn from the main thread, allowing us to
>> control the multithreading
>> 3. Orders will be treated as an event and will be set to expire in a
>> certain
>> amount of time, allowing us to mange the memory footprint of each
>> session.
>>
>> Does this sound reasonable based on what you know of our usecase?
>> Additionally with expiring Orders does this cause a reevaluation of the
>> rules when the expiration occurs? The only other question I have is does
>> the
>> expiration clock start when no more activation's get created for the
>> given
>> event?
>>
>> Thanks again.
>>
>> --
>> View this message in context:
>> http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3795920.html
>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users at .jboss
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> 
> _______________________________________________
> rules-users mailing list
> rules-users at .jboss
> https://lists.jboss.org/mailman/listinfo/rules-users
> 

--
View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3796613.html
Sent from the Drools: User forum mailing list archive at Nabble.com.