[rules-users] Drools & JBPM Persistence

[Mauricio Salatino]

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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120622/fe7d85a6/attachment.html