[jboss-jira] [JBoss JIRA] (JBRULES-3108) problems with concurrent process executions, constraints, and multiple sessions

[J Xmith (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743012#comment-12743012 ] 

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