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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > [email protected] > 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. _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
