Hi, I'm opening this thread in the aim of generating a debate about the approach to session persistence in Drools and JBPM for BPMN processes which by definition are able to generate asynchronous human tasks. IMHO the current approach needs to be refactored in favor of joining the management of the different Drools and JBPM entities in an unique manager. The current implementation offers two managers one in Drools, one in JBPM. Each of this managers are wrappers of a shared JPA EntityManager context and manage their own entities. When the integration of JBPM into Drools was done ( leaving behind drools flow ), the approach seemed to be to make the entities in JBPM ( workitems, processinstance and so on ) look like the entities in Drools. As a result, the implementation of those entities in JBPM now implement the interfaces of the same entities in Drools. That looked like a good approach, but the experience, at least mine, seems to reveal it as not that good. In my opinion, the first problem with that approach is that Drools, the reteoo algorithm, runs in a single-threaded environment. Drools persistence was designed having this in mind, so for the code in Drools, there's no doubt that when in a persistent enviroment, the transaction, if any, will be bound to the same thread as the one in which the reteoo algorithm is executed. That leads to situations where whenever a class in JBPM calls drools in a JBPM's thread ( the mina handler thread, a NIO one for instance ), Drools thinks that is being executed in it's own thread ( where things are expected, as the JTA transaction bound for example ) and clearly, in some situations it is not the case. Then Drools expects to find certain resources and certain environment which are not always there. Leading to failure. As Drools now is a dependency for JBPM through the Knowledge-API, I think that the management of the persistence for Drools and JBPM should be merged in one that makes no assumptions and manages the needs for persistence in a coherent way for both products. What do you think? "There can be only one" -> http://en.wikipedia.org/wiki/Highlander_%28film%29 Alberto R. Galdo argaldo(a)gmail.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

No, I didn't. I need to be able to deploy the human task server and my knowledge session in separate JVM's. And Mina is on my way. The fact that I am able to do things in some other way doesn't make this very problem dissapear ... :(. In fact, this will never dissapear unless some communication mechanism between Drools & JBPM is developed to allow the processes to be executed inside Drools Reteoo thread. Isn't that so? Alberto R. Galdo argaldo(a)gmail.com On Fri, Jun 22, 2012 at 2:17 PM, Mauricio Salatino <salaboy(a)gmail.com&gt;wrote: > Both persistence mechanisms are already unified. > the jBPM-persistence module extends the Drools one adding the relevant > entities by the processes. > > You can be having problems with the Mina Server, did you try the local > configuration? The Mina Server was designed to run in a different JVM than > the session, as a standalone component, if you are running it in the same > JVM that can be causing some transactional problems as you mention. If you > need to run it in the same JVM you can use the local configuration, did you > try that? > Cheers > > On Fri, Jun 22, 2012 at 8:31 AM, Alberto R. Galdo <argaldo(a)gmail.com&gt;wrote: > >> Hi, >> >> I'm opening this thread in the aim of generating a debate about the >> approach to session persistence in Drools and JBPM for BPMN processes which >> by definition are able to generate asynchronous human tasks. >> >> IMHO the current approach needs to be refactored in favor of joining >> the management of the different Drools and JBPM entities in an unique >> manager. >> >> The current implementation offers two managers one in Drools, one in >> JBPM. Each of this managers are wrappers of a shared JPA EntityManager >> context and manage their own entities. >> >> When the integration of JBPM into Drools was done ( leaving behind >> drools flow ), the approach seemed to be to make the entities in JBPM ( >> workitems, processinstance and so on ) look like the entities in Drools. As >> a result, the implementation of those entities in JBPM now implement the >> interfaces of the same entities in Drools. That looked like a good >> approach, but the experience, at least mine, seems to reveal it as not that >> good. >> >> In my opinion, the first problem with that approach is that Drools, >> the reteoo algorithm, runs in a single-threaded environment. Drools >> persistence was designed having this in mind, so for the code in Drools, >> there's no doubt that when in a persistent enviroment, the transaction, if >> any, will be bound to the same thread as the one in which the reteoo >> algorithm is executed. That leads to situations where whenever a class in >> JBPM calls drools in a JBPM's thread ( the mina handler thread, a NIO one >> for instance ), Drools thinks that is being executed in it's own thread ( >> where things are expected, as the JTA transaction bound for example ) and >> clearly, in some situations it is not the case. Then Drools expects to find >> certain resources and certain environment which are not always there. >> Leading to failure. >> >> As Drools now is a dependency for JBPM through the Knowledge-API, I >> think that the management of the persistence for Drools and JBPM should be >> merged in one that makes no assumptions and manages the needs for >> persistence in a coherent way for both products. >> >> What do you think? >> >> >> "There can be only one" -> >> http://en.wikipedia.org/wiki/Highlander_%28film%29 >> >> >> Alberto R. Galdo >> argaldo(a)gmail.com >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > -- > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jugargentina.org > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

I see your point, but IMHO that doesn't mean that in certain circumstances, when the process is being executed in a thread that it is no the same thread as the one in which drools is executing leads to a situation in which the persistence mechanisms are not enough to allow a fault tolerant JBPM for long-time running processes. As mentioned, there is at least one scenario, at least when mina is involved, where things are broken. Alberto R. Galdo argaldo(a)gmail.com On Fri, Jun 22, 2012 at 2:50 PM, Mauricio Salatino <salaboy(a)gmail.com&gt;wrote: > I think that you are mixing things up. > Did you take a look at the CommandBasedStatefulKnowledgeSession? > Every command that represent an operation against the knowledge session > is being executed inside a transaction, for both rules and processes. As > soon as a safe point is found (for both processes and rules) the > persistence mechanism commits the transaction. > > "In fact, this will never dissapear unless some communication mechanism > between Drools & JBPM is developed to allow the processes to be executed > inside Drools Reteoo thread." > Take a look at the class that I mention and then try to explain me what > you mean with the previous sentence. > > Cheers > > > On Fri, Jun 22, 2012 at 9:45 AM, Alberto R. Galdo <argaldo(a)gmail.com&gt;wrote: > >> >> No, I didn't. I need to be able to deploy the human task server and my >> knowledge session in separate JVM's. And Mina is on my way. >> >> The fact that I am able to do things in some other way doesn't make this >> very problem dissapear ... :(. In fact, this will never dissapear unless >> some communication mechanism between Drools & JBPM is developed to allow >> the processes to be executed inside Drools Reteoo thread. >> >> Isn't that so? >> >> >> Alberto R. Galdo >> argaldo(a)gmail.com >> >> >> >> On Fri, Jun 22, 2012 at 2:17 PM, Mauricio Salatino <salaboy(a)gmail.com&gt;wrote: >> >>> Both persistence mechanisms are already unified. >>> the jBPM-persistence module extends the Drools one adding the relevant >>> entities by the processes. >>> >>> You can be having problems with the Mina Server, did you try the local >>> configuration? The Mina Server was designed to run in a different JVM than >>> the session, as a standalone component, if you are running it in the same >>> JVM that can be causing some transactional problems as you mention. If you >>> need to run it in the same JVM you can use the local configuration, did you >>> try that? >>> Cheers >>> >>> On Fri, Jun 22, 2012 at 8:31 AM, Alberto R. Galdo <argaldo(a)gmail.com&gt;wrote: >>> >>>> Hi, >>>> >>>> I'm opening this thread in the aim of generating a debate about the >>>> approach to session persistence in Drools and JBPM for BPMN processes which >>>> by definition are able to generate asynchronous human tasks. >>>> >>>> IMHO the current approach needs to be refactored in favor of >>>> joining the management of the different Drools and JBPM entities in an >>>> unique manager. >>>> >>>> The current implementation offers two managers one in Drools, one >>>> in JBPM. Each of this managers are wrappers of a shared JPA EntityManager >>>> context and manage their own entities. >>>> >>>> When the integration of JBPM into Drools was done ( leaving behind >>>> drools flow ), the approach seemed to be to make the entities in JBPM ( >>>> workitems, processinstance and so on ) look like the entities in Drools. As >>>> a result, the implementation of those entities in JBPM now implement the >>>> interfaces of the same entities in Drools. That looked like a good >>>> approach, but the experience, at least mine, seems to reveal it as not that >>>> good. >>>> >>>> In my opinion, the first problem with that approach is that Drools, >>>> the reteoo algorithm, runs in a single-threaded environment. Drools >>>> persistence was designed having this in mind, so for the code in Drools, >>>> there's no doubt that when in a persistent enviroment, the transaction, if >>>> any, will be bound to the same thread as the one in which the reteoo >>>> algorithm is executed. That leads to situations where whenever a class in >>>> JBPM calls drools in a JBPM's thread ( the mina handler thread, a NIO one >>>> for instance ), Drools thinks that is being executed in it's own thread ( >>>> where things are expected, as the JTA transaction bound for example ) and >>>> clearly, in some situations it is not the case. Then Drools expects to find >>>> certain resources and certain environment which are not always there. >>>> Leading to failure. >>>> >>>> As Drools now is a dependency for JBPM through the Knowledge-API, I >>>> think that the management of the persistence for Drools and JBPM should be >>>> merged in one that makes no assumptions and manages the needs for >>>> persistence in a coherent way for both products. >>>> >>>> What do you think? >>>> >>>> >>>> "There can be only one" -> >>>> http://en.wikipedia.org/wiki/Highlander_%28film%29 >>>> >>>> >>>> Alberto R. Galdo >>>> argaldo(a)gmail.com >>>> >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> >>> -- >>> - MyJourney @ http://salaboy.wordpress.com >>> - Co-Founder @ http://www.jugargentina.org >>> - Co-Founder @ http://www.jbug.com.ar >>> >>> - Salatino "Salaboy" Mauricio - >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > -- > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jugargentina.org > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

What I'm pointing out is that at certain circumstances, such as when a human task is completed in a HT Server that connects to the execution context in JBPM ( we've tested this with Mina ), the execution of the JBPM process lives in the same thread as the one that receives the message ( a NIO Channel ) and this makes the persistence go wrong.

But in our experience, this is not the only case where persistence can be wrong, there are others, such as when using Fusion events are involved with process instances in an persistent environment ... What kind of problems? If your stream of events is aggressive, your

That's why we thought that maybe another approach to persistence, now that Drools & JBPM are tied, is needed. Cheers

Alberto R. Galdo argaldo(a)gmail.com On Fri, Jun 22, 2012 at 3:05 PM, Mauricio Salatino <salaboy(a)gmail.com&gt;wrote: > Drools and jBPM are being executed in the same thread, in your set up > mina is not. Is that what are you pointing out? > Did you really need to have mina in a separate JVM or you can use the > Local Implementation? > Cheers > > > On Fri, Jun 22, 2012 at 10:00 AM, Alberto R. Galdo <argaldo(a)gmail.com&gt;wrote: > >> >> I see your point, but IMHO that doesn't mean that in certain >> circumstances, when the process is being executed in a thread that it is no >> the same thread as the one in which drools is executing leads to a >> situation in which the persistence mechanisms are not enough to allow a >> fault tolerant JBPM for long-time running processes. >> >> As mentioned, there is at least one scenario, at least when mina is >> involved, where things are broken. >> >> Alberto R. Galdo >> argaldo(a)gmail.com >> >> >> >> On Fri, Jun 22, 2012 at 2:50 PM, Mauricio Salatino <salaboy(a)gmail.com&gt;wrote: >> >>> I think that you are mixing things up. >>> Did you take a look at the CommandBasedStatefulKnowledgeSession? >>> Every command that represent an operation against the knowledge session >>> is being executed inside a transaction, for both rules and processes. As >>> soon as a safe point is found (for both processes and rules) the >>> persistence mechanism commits the transaction. >>> >>> "In fact, this will never dissapear unless some communication mechanism >>> between Drools & JBPM is developed to allow the processes to be executed >>> inside Drools Reteoo thread." >>> Take a look at the class that I mention and then try to explain me what >>> you mean with the previous sentence. >>> >>> Cheers >>> >>> >>> On Fri, Jun 22, 2012 at 9:45 AM, Alberto R. Galdo <argaldo(a)gmail.com&gt;wrote: >>> >>>> >>>> No, I didn't. I need to be able to deploy the human task server and my >>>> knowledge session in separate JVM's. And Mina is on my way. >>>> >>>> The fact that I am able to do things in some other way doesn't make >>>> this very problem dissapear ... :(. In fact, this will never dissapear >>>> unless some communication mechanism between Drools & JBPM is developed to >>>> allow the processes to be executed inside Drools Reteoo thread. >>>> >>>> Isn't that so? >>>> >>>> >>>> Alberto R. Galdo >>>> argaldo(a)gmail.com >>>> >>>> >>>> >>>> On Fri, Jun 22, 2012 at 2:17 PM, Mauricio Salatino <salaboy(a)gmail.com&gt;wrote: >>>> >>>>> Both persistence mechanisms are already unified. >>>>> the jBPM-persistence module extends the Drools one adding the >>>>> relevant entities by the processes. >>>>> >>>>> You can be having problems with the Mina Server, did you try the >>>>> local configuration? The Mina Server was designed to run in a different JVM >>>>> than the session, as a standalone component, if you are running it in the >>>>> same JVM that can be causing some transactional problems as you mention. If >>>>> you need to run it in the same JVM you can use the local configuration, did >>>>> you try that? >>>>> Cheers >>>>> >>>>> On Fri, Jun 22, 2012 at 8:31 AM, Alberto R. Galdo <argaldo(a)gmail.com&gt;wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm opening this thread in the aim of generating a debate about >>>>>> the approach to session persistence in Drools and JBPM for BPMN processes >>>>>> which by definition are able to generate asynchronous human tasks. >>>>>> >>>>>> IMHO the current approach needs to be refactored in favor of >>>>>> joining the management of the different Drools and JBPM entities in an >>>>>> unique manager. >>>>>> >>>>>> The current implementation offers two managers one in Drools, one >>>>>> in JBPM. Each of this managers are wrappers of a shared JPA EntityManager >>>>>> context and manage their own entities. >>>>>> >>>>>> When the integration of JBPM into Drools was done ( leaving >>>>>> behind drools flow ), the approach seemed to be to make the entities in >>>>>> JBPM ( workitems, processinstance and so on ) look like the entities in >>>>>> Drools. As a result, the implementation of those entities in JBPM now >>>>>> implement the interfaces of the same entities in Drools. That looked like a >>>>>> good approach, but the experience, at least mine, seems to reveal it as not >>>>>> that good. >>>>>> >>>>>> In my opinion, the first problem with that approach is that >>>>>> Drools, the reteoo algorithm, runs in a single-threaded environment. Drools >>>>>> persistence was designed having this in mind, so for the code in Drools, >>>>>> there's no doubt that when in a persistent enviroment, the transaction, if >>>>>> any, will be bound to the same thread as the one in which the reteoo >>>>>> algorithm is executed. That leads to situations where whenever a class in >>>>>> JBPM calls drools in a JBPM's thread ( the mina handler thread, a NIO one >>>>>> for instance ), Drools thinks that is being executed in it's own thread ( >>>>>> where things are expected, as the JTA transaction bound for example ) and >>>>>> clearly, in some situations it is not the case. Then Drools expects to find >>>>>> certain resources and certain environment which are not always there. >>>>>> Leading to failure. >>>>>> >>>>>> As Drools now is a dependency for JBPM through the Knowledge-API, >>>>>> I think that the management of the persistence for Drools and JBPM should >>>>>> be merged in one that makes no assumptions and manages the needs for >>>>>> persistence in a coherent way for both products. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>>> "There can be only one" -> >>>>>> http://en.wikipedia.org/wiki/Highlander_%28film%29 >>>>>> >>>>>> >>>>>> Alberto R. Galdo >>>>>> argaldo(a)gmail.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> - MyJourney @ http://salaboy.wordpress.com >>>>> - Co-Founder @ http://www.jugargentina.org >>>>> - Co-Founder @ http://www.jbug.com.ar >>>>> >>>>> - Salatino "Salaboy" Mauricio - >>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> >>> -- >>> - MyJourney @ http://salaboy.wordpress.com >>> - Co-Founder @ http://www.jugargentina.org >>> - Co-Founder @ http://www.jbug.com.ar >>> >>> - Salatino "Salaboy" Mauricio - >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > -- > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jugargentina.org > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users