Users changing rules IS the correct use-case of drools (I would even say that if rules never change, drools is likely to be worse than pure java). What others said is "changing the rules at each request by regenerating and recompiling" is not.
I can't imagine that users may change rules at each request, so you must have, at least for some time (thus a lot of requests), a stable rule base. What is costly is to compile rules, but you already know that. So the idea is to keep in some kind of cache the actual rules, and only recompile them when they change. The source of rules does not matter : you can generate the DRL according to your configuration, or make you users directly write rules (with guvnor, which will fits well if your rules are only basic filters). The optimisation you have to do is to keep your compiled rules somewhere (by serializing your KnowlegdePackages or simply keep it in a kind of map), and reuse it until your source change : you have to find a way to detect that rules (or the config that is used to generate them) have changed, and then recompile a new up-to-date KnowledgePackage. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
