[rules-users] Drools & JBPM Persistence

[Alberto R. Galdo]

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 at gmail.com


On Fri, Jun 22, 2012 at 2:17 PM, Mauricio Salatino <salaboy at gmail.com>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 at gmail.com>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 at gmail.com
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120622/f6e3ea7a/attachment-0001.html