It's difficult proposing alternatives without knowing all the requirements.
If there are no rules that require the presence of transactions with unknown/indeterminate account numbers, a caching strategy might be considered. Clearly, this would render relying on Fusion features obsolete, and (temporary) retractions would have to be done explicitly. Most frequently used accounts would remain in WM up for the period you have to consider. Others would drop out due to being idle for a certain period. A new transaction for some swapped out account would trigger reloading of old transactions. (This is akin to some page swapping strategy used to implement virtual memory in operating systems.) This isn't a simple task, but given the huge amount of transactions you have to cope with you may not have any feasible alternative "out of the box". -W On 15 June 2012 03:32, chrisLi <[email protected]> wrote: > Hi, > > Thank you very much for so qucik response. I cannot even believe it! > > As far as I know, the Fusion engine has to store the event details for > sliding windows. Because if an event > > in the window is expired, the Fusion engine still need this event details > to update the accumulate results. > > So, I think storing the accumulate results for per day could not conform to > Fusion's logic. > > > Thank you, all! > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/Is-a-single-StatefulKnowledgeSession-with-Distributed-Memory-cache-possible-tp4017968p4017977.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
