Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: Rule as a singleton bean #192

Open
ykorobitsin opened this issue May 5, 2020 · 3 comments
Open

Q: Rule as a singleton bean #192

ykorobitsin opened this issue May 5, 2020 · 3 comments

Comments

@ykorobitsin
Copy link

ykorobitsin commented May 5, 2020

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?
@awattez
Copy link
Contributor

awattez commented May 8, 2020

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.

@ykorobitsin
Copy link
Author

ykorobitsin commented May 8, 2020

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?

@awattez
Copy link
Contributor

awattez commented May 8, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants