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-tp3793...
> Sent from the Drools: User forum mailing list archive at
Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users@.jboss
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users@.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-tp3793...
Sent from the Drools: User forum mailing list archive at
Nabble.com.