[rules-users] problems with process executions, constraints, and multiple sessions

[Jordi Alvarez]

Hello, regarding this point,

As a temporal patch, we have tried to directly modify drools-jpa
module behaviour by:

- 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 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.

After these modifications have been performed, the execution of processes
with intensive use of wait states has executed correctly, and no confussion
has been detected between process instances after the execution of some
stress tests that previously originated a lot of instances of the problem.

We will open an incident in Drools-JIRA regarding this issue.

best regards,
Jordi Alvarez


2011/6/22 Jordi Alvarez <jalvarezc at gmail.com>

> Hi, after a bit more of study we have seen that the problem is in the JPA
> Query defined in META-INF/orm.xml of drools-persistence-jpa-5.1.1.jar
> (ProcessInstancesWaitingForEvent).
>
> This query, for version 5.1.1 of drools seems not to be prepared for
> storing multiple stateful sessions in the same database schema.
>
> In fact, the original query we got from the .jar was not properly working,
> and, while in project startup, we created our own orm.xml file with an
> updated query, such as described in:
>
> http://www.mail-archive.com/rules-users@lists.jboss.org/msg16068.html
> But the "good" query (and also the original in the jar file) seems to be
> not prepared for working with more than one stateful session stored in the
> same database schema and having exactly the same constraint "activated".
> Should we open a JIRA for this?
>
> We have looked at source code in version 5.2 / jBPM 5, and the query is
> similar, with no reference to the stateful session. It should really be
> prepared for multiple sessions stored in the same database schema?
>
> thanks again,
> Jordi Alvarez
>
>
> 2011/6/22 Jordi Alvarez <jalvarezc at gmail.com>
>
>> Hello,
>>
>> I am involved in a project in which we are using Drools as the BPM.
>>
>> We are experiencing some problems with wait state nodes. More concretely,
>> the problem seems to deal with
>> the execution of constraints in those wait states.
>>
>> Let me first describe our context:
>>
>> We are using JPA with Hibernate and Oracle. Our process instances are all
>> identified by a
>> business identifier (a string). This business identified would correspond
>> to the identifier of a case;
>> and a case normally has associated a process instances (and subprocesses
>> of that process).
>>
>> Additionally, the processes we have developed make extensive
>> use of timers and wait states with constraints that refer to the process
>> instance and other facts that
>> we are using as events.
>>
>> We have a stateful session for every case / business identifier.
>>
>> We have a main process that calls subprocesses. As we said, in that
>> process and subprocesses we use wait states.
>> The constraints in those wait states are "waiting" for a fact to be
>> inserted in the stateful session. Once
>> the corresponding fact is inserted, the corresponding constraint should be
>> activated.
>>
>> At this point is where the problem arises. All the constraints have been
>> unit tested with no problem at all.
>>
>> But we have detected some problems that can arise when there is more that
>> one process waiting in the same wait state
>> (every process in a different Drools stateful session).
>>
>> The situation is as follows:
>>
>> 1. There is a main process instance MPA with business id BA that has a
>> subprocess SPA (also with the same business id).
>> This subprocess is waiting in a given wait state W1 (these processes are
>> running in the stateful
>> session corresponding to the business id BA, from now on SA).
>>
>> 2. There is a second main process and subprocess with business id BB. The
>> state for these second set of processes is the
>> same one, and they are running in a second stateful session (the one for
>> business id BB), from now on SB.
>>
>> 3. A fact FA is inserted in SA. This fact makes the constaint in SPA true,
>> which makes SPA to leave the wait
>> state and continue with the execution.
>>
>> Then, in some situations stateful session SA tries to also continue SPB,
>> which runs in a different stateful session
>> (that of SB). That, of course, produces some posterior problems that were
>> the origin of our investigations.
>> After some more deep investigations, it seems that the reason session SA
>> tries to continue SPB is that the constraint
>> in W1 for SPA gets activated twice. We have detected (and posteriorly
>> corrected) some situations in which this happens.
>>
>> For example: the process in the constraint was associated not only to SPA
>> but to other processes in SA (the main process SPA for example).
>> we corrected this and obtained a better behaviour in which the problem is
>> more difficult to reproduce.
>>
>> We have tried also to replace constraints with rule nodes, and set the
>> lock-on-active and no-loop. The results were a bit different
>> but seemed not to avoid the problem.
>>
>> So, there is someone that has experimented situations similar to the
>> described above? Additionally, can someone from the drools
>> team give a bit of light to this situation? Why the reasonings in a
>> stateful session are interacting with processes running on a different
>> stateful session?
>>
>> many thanks in advance,
>> Jordi Alvarez
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110623/e487cdb2/attachment.html