[JBoss JIRA] (JBRULES-3108) problems with concurrent process executions, constraints, and multiple sessions
8:56 a.m.
[
https://issues.jboss.org/browse/JBRULES-3108?page=com.atlassian.jira.plug...
]
J Xmith commented on JBRULES-3108:
----------------------------------
I am using jbpm 5.3.0.Final, and I am facing the same problem:
I have a fairly simple business process with one rule-group (Guvnor TaskType=Business
Rule). The rule-group does validations on process variables. To provide separation between
facts from different requests, each processing request creates its own stateful knowledge
session which in turns creates its own business process. Everything works well with one
process execution (one request at a time).
When 2 almost concurrent requests are tried (each one running in its own thread), the
first one reaching the rule-group leave an entry/record inside the EVENTTYPES table
(containing the businessProcessId and the ruleflow group's name), and when the second
business process reaches the rule-group it gets as event the one stored in the EVENTTYPES
table. From that moment onwards, the second thread continues its execution on the first
business process. The end result is, the first business process get executed twice.
Removing the rule-group makes the concurrent requests to work well.
I was thinking in a similar solution to the one proposed here by Jordi Alvarez (using the
knowledge session Id as an extra identifier, etc), however I realised this Jira issue has
been open for too long now, and not updates since then. What is the intended behaviour of
the EVENTTYPES table, and why the knowledge session Id is not already used to distinguish
between multiple concurrent requests?
problems with concurrent process executions, constraints, and
multiple sessions
-------------------------------------------------------------------------------
Key: JBRULES-3108
URL: https://issues.jboss.org/browse/JBRULES-3108
Project: JBRULES
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-core (flow)
Affects Versions: 5.1.1.FINAL, 5.2.0.Final
Environment: Independent of OS, JVM, and Application Server. Reproduced in a
windows development environment with a Sun JVM. Also reproduced in linux. Also database
independent: reproduced with Oracle RDBMS and HSQLDB.
Reporter: Jordi Alvarez
Assignee: Kris Verlaenen
The context is as follows:
1. We have drools flow configured with JPA and Hibernate, accessing an Oracle / HSQLDB
database (depending on the environment).
2. We do have several concurrent stateful sessions in which different instances of the
same kind of processes are running. These stateful sessions are persisted in the same
database schema.
3. We do use wait states (also reproduced with rule nodes) that have constraints that
wait for a fact to be inserted into the stateful session.
4. Whenever the fact that makes the constraint to satisfy is inserted for one process in
a given stateful session; if there are other processes waiting in that wait
state/constraint (in other different stateful sessions), the stateful session tries also
to continue those process executions, even when they are not part of it.
A solution has been implemented temporally over drools source code (in order to get our
context working): the solution is briefly described in the forum url below. For
completeness a summary is included here:
- Adding a new attribute to org.drools.persistence.processinstance.ProcessInstanceInfo
POJO identifying the stateful session to which the process instance corresponds (and the
corresponding DB column).
- modifying the ProcessInstancesWaitingForEvent query (in orm.xml) in order to take into
account the session id as a (new) second parameter.
- modify the class org.drools.persistence.processinstance.JPASignalManager in order to
execute the query with both parameters.
- as a quick way to have the session id, we have a threadlocal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4138
days inactive
4138
days old
0 comments
1 participants
participants (1)
-
J Xmith (JIRA)