[jboss-user] [jBPM] - Re: jboss as 5 jbpm 5.1 persistence

[Victor Zorin]

Victor Zorin [http://community.jboss.org/people/zorin] created the discussion

"Re: jboss as 5 jbpm 5.1 persistence"

To view the discussion, visit: http://community.jboss.org/message/603549#603549

--------------------------------------------------------------
Note sure if you find any hints here, but this is the way we currently handle similar situations, I mean bringing together EJB Session transaction management and JBPM5. 

What we found is that the major issue with JBPM StatefulKnowledgeSession is that it does not attach itself to CMP transaction during the startProcess(...) or signal(...). Playing with Bitronix Transaction manager did bring much help.

However, any subsequent calls from the workflow to EJB Session methods work as they should (i.e. JBoss's transaction manager attaches itself well to a transaction that is started from process instance). For example, transaction is executed properly when making a call from Script node to local or remote interface of an EJB session.

So, without breaking the framework, and until a proper fix or better workaround is found, we use the following approach to transaction management:

When invoking ksession.startProcess(...) or signal(...) from within CMP Session, mark relevant EJB session method as @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED), and do manual transaction management of your records, while making sure that ksession methods are invoked without the transaction, eg.:

@Stateless
public class InstanceManager implements InstanceManagerRemote,
        InstanceManagerLocal {
...
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED
public long createLicenseManagementProcess(String procId, ...)
{
     ...
     // create workflow instance, WITHOUT TX!!!!
    ProcessInstance inst = ksession.startProcess(procId);

    // handle your own EJB Entity records
    UserTransaction tx = (UserTransaction) new InitialContext().lookup("java:comp/UserTransaction");
    logger.info("have UserTransaction " + tx.toString());
    tx.begin();
    LicenseEntity entity = new LicenseEntity();
    entity.setWorkflowInstanceId(inst.getId());
    ...
    em.persist();
    tx.commit();
}


// this is the method which is called from ProcessEventListener
public void callbackProcessCompleted(long workflowId)
{
  // no need to do manual transaction handling
  ... update your own record status using EntityManager directly
}

// this is the method which is called from BPMN Script via Local interface
public void paymentMade(long workflowId, ....)
{
  // no need to do manual transaction handling
  ... create payment record status using EntityManager directly
}

} // end of stateless session bean

Here is an important bit. 
If the first node of a workflow tries to get back to EJB Session, make sure that your data is already there and commited to the database.
Have a look again at createLicenseManagementProcess(...) method.
- First step: we create a process, by calling startProcess(...).
- Second step: we create own record by storing the workflow Id of a created process.
- If the first node in a workflow is a Script which tries to get back to and call any method, such as paymentMade(long workflowId), transaction will work properly, but data will not be there yet. 

One of the solutions/tricks, is breaking the transaction by breaking the workflow via making a first node to be an Event Node waiting for 'start' event. See extended code below:

    // create workflow instance, WITHOUT TX!!!!
    // but now this workflow will stop on first Event Node waiting for 'start' signal
    ProcessInstance inst = ksession.startProcess(procId);

    // handle your own EJB Entity records
    ...
    tx.commit();

    // all data is commited, now we can kick-start the workflow
    ksession.signalEvent("start", null, inst.getId());
    // this is the end of startPrtocess method
}

[Disclaimer: We did not have a lot of time to do deep investigation why things do not work as we think they should, so we had to quickly come up with own approach to persistence, transaction handling, clustering and safe restarts of JBoss AS. This approach may limit the use of BPMN and JBPM API, but can not bend the rules. So when a better solution is found, system would remain backward compatible.]
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/603549#603549]

Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2034]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20110504/ce528e1c/attachment-0001.html