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