[rules-users] Design guidelines regarding session pools

Mikael Larsson mikael.larsson at redpill.se
Tue Nov 20 07:28:41 EST 2007


Hi!

I have some questions about multithreaded apps and if it is necessary to 
pool session objects for performance.

* I understand that it is expensive to create the RuleBase objects but 
what about the sessions?
If I create a new stateful session object for each request will that 
become a potential bottleneck?

* Is the session class thread safe, what will happen if  two or more 
threads simultaneously call fireAllRules on one and the same session 
object?

One advantage of pooling session is if you have some data that does not 
change per request. Say that I have some data associated with a specific 
type of request that should be inserted for all requests of that 
particular type and evaluated towards request specific stuff, e.g. 
params in the request. E.g. An object that specifies allowed values for 
a particular API will be the same for all requests (well at least until 
you reconfigure the allowed values...) and the rules would evaluate the 
request specific value based on the "allowed values" object. In this 
case only the request specific parameter/value needs to be 
inserted/retracted per request.

* I would rather use StatefulSession instead of stateless since I find 
the API more flexible, are there any performance considerations I should 
be aware of? If pooling is necessary I guess I must use the stateful 
session. But if creating one session per request, are there any concrete 
reasons for using the stateless session (besides the simpler API and 
that I need to call dispose on the stateful session)?

Kind of hoping that the answer will be: "No, pooling will not be 
necessary.", but any feedback about situations where it may be necessary 
for best performance would be much appreciated.
Regards,
/Mikael




More information about the rules-users mailing list