Problems using jBPM from JBoss

[iterrell]

I'll be the first to admit, I've had more than a tiny bit of difficulty using jBPM as our workflow solution. I had several issues with timer and subProcessInstance persistence with 3.0.2, so I switched today to 3.1. However, now I'm having some problems I didn't have before, even before I've worked out the ones I did have. :)

I listed one problem with process definition deployment here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77406

I'm still having problems with persistence: it appears that in the database my tokens have null processInstance_, parent_, and subProcessInstance_ fields, and the ProcessInstance rows have null superProcessToken_ fields.

What confuses me is that in my current persistence problems the rows are being saved in the database, but those key parts are missing.

I'm trying to use jBPM in a clustered JBoss 4.0.3 environment, and the processes I've designed so far use timers and subprocesses significantly. (Here's a previous post describing some of my timer trouble: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77192).

I've tried to tell jBPM about my transactions with this in hibernate.cfg.xml:

<property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
 <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>

My workflows are all fairly complex (and long), but I've tested them using a web application and they all seem to work. However, going to JBoss seems to introduce a fair amount of trouble. Are there restrictions on what can go on within one transaction? For instance, my application creates a process instance, starts it with a signal(), and according to workflow rules it advances into a subprocess which creates a timer for later automatic advancement, *all* before the session bean returns and the transaction ends. Does that have any effect on persistence?

If anyone has any ideas on this, or any information about exactly how and where I should be saving (now via jbpmContext.save()) things, please let me know.

Ian

[koen.aers]

Ian,

Can you post your exact issues? It is kind of difficult to figure out what is wrong without having actual logging and/or processdefinitions.

Regards,
Koen

[iterrell]

Koen,

Thanks for your response. Also, I apologize, I'm usually much better at posting symptoms of problems. I migrated to 3.1 to try to correct issues I was having with 3.0.2, and it was on the whole a long and frustrating day. :)

In the course of getting the information together for this reply I found the cause of the main migration issue I was having (as is often the case, I know). The first symptom was that when deploying the process definition it would not be completely saved to the database, as such with the NULL start state:

mysql> select * from jbpm_processdefinition;
+-----+-------------+----------+------------------------+-------------+
| ID_ | NAME_ | VERSION_ | ISTERMINATIONIMPLICIT_ | STARTSTATE_ |
+-----+-------------+----------+------------------------+-------------+
| 2 | Simple Test | 1 | | NULL |
+-----+-------------+----------+------------------------+-------------+

The cause of the issue was that I mis-upgraded my JbpmContext (formerly JbpmSession) interceptor I was not actually closing the jbpmContext. That has since been fixed, and I'll now move on to testing the issues this whole migration was hoped to fix. :)

Thanks again,
Ian