deliveredtechnologies/rulebook

Q: Rule as a singleton bean

ykorobitsin opened this issue · 3 comments

Am I correct that in case rules are defined as spring singleton beans it means that all the application threads will be blocked by the single lock in Result class?

Or I can reformulate the question:

  1. what are the outcomes when we have rules set as singleton beans?
  2. Should I defined rule beans as session scoped?

In com.deliveredtechnologies.rulebook.spring.RuleBean you have @Scope("prototype")
Scope prototype means that every time you ask spring (getBean or dependency injection) for an instance it will create a new instance and give a reference to that.

If you check at com.deliveredtechnologies.rulebook.model.runner.AbstractRuleBookRunner

there is a call to Object ruleInstance = getRuleInstance(rule); inside run function.
For each rule object it will create a new instance.

In com.deliveredtechnologies.rulebook.Result class you have a Map and a lock in order to deal with asynchronous problem:

  private Map<Long, T> _valueMap = new HashMap<>();
  private final ReentrantReadWriteLock _lock = new ReentrantReadWriteLock();

If you have one run per request, on each request you will have a different bean/object for each @RuleBean or @Rule POJOs.
You don't have to define Session scoped.

AbstractRuleBookRunner

I see the single result that keeps results per thread. Does it mean that we have single lock in result for all the application threads? Is it really optimized for all threads to wait when a single request finishes its work?

You are right one Result, we have one ReentrantReadWriteLock _lock for all the application threads. But locks take place only during reading and writing (it is not exactly the same locks in reading as writing) not during the global processing.