[rules-users] Drools & JBPM Persistence

Alberto R. Galdo argaldo at gmail.com
Fri Jun 22 07:31:26 EDT 2012


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


More information about the rules-users mailing list