Hello; this is probably a pretty basic kind of question, but I want to see what other users' tricks are for managing memory in their sessions.<br><br>My application is a straightforward survey-type application. There are questions, choices, answers (choice selections) and so on. Once someone has selected an answer, the rule evaluation kicks in. The determination of which question to show next is made based on...well, pretty much anything. Typically it's on the current user's last answer to a question, but it might also involve his answers to several previous questions in his own path through the survey.<br>
<br>This being psychology-related, there are hundreds of questions and probably hundreds of rules. "If the question the user just answered is question 4, and if the user selected 'sometimes' as the answer to question 4, and if he also selected 'never' as the answer to question 1 during this interview session, and he is over 40, then show him question 25 next" is a good example of one such rule. You can see how there might be nearly one rule for each question.<br>
<br>(The rulebase session itself could probably be sequential--none of the facts in the session is modified in such a way that reevaluation of the rulebase is necessary.)<br><br>OK, so, currently I load pretty much everything into the (stateful) knowledge session I have. That means--what with all the question text and answer text and everything--there is a LOT of data in this particular session. Multiply times the number of concurrent interviews being administered and this thing chews through heap in a hurry.<br>
<br>One approach I thought of was to simply load the current question into the session as a fact and then rely on various accumulate functions to load other questions and answers as necessary. But this approach isn't much better than a linear series of if/then statements, if I understand correctly.<br>
<br>What are some of the so-called best practices here? Are there particular Drools-centric development approaches I should be taking, or architectural choices I should be making? Or is this just a case of throw hardware at the problem? :-)<br>
<br>Again, I'm not so much looking for A Single Right Answer as I am reports from the field. You may feel free to contact me directly if you wish.<br><br>Best,<br>Laird<br clear="all"><br>-- <br><a href="http://about.me/lairdnelson" target="_blank">http://about.me/lairdnelson</a><br>
<br>