We are evaluating jbpm for concurrency.

We created a test case with a lot of concurrency.

The test process has:

• a fork
• 10 nodes with async="true" and
• a join with lock="pessimistic".

In some of the parallel nodes we get the exception:
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): org.jbpm.graph.exe.Token#121
We checked that the lock mode is persisted correctly and that the join node actually does the lock.UPGRADE.

We attach the testcase, the test process definition, and the full stacktrace.

We enforced a stricter locking strategy, namely locking the process instance for as long as the command executor was working and the test worked ok.
However, we finally dropped this solution because it was creating a lot of row locks and could lead to transaction timeouts and finally chose another solution.

All of our business logic is in nodes with async="true" and goes through the jms executor.
We serialize consumption of jms messages belonging to the same process instance by using a JMS extention of Weblogic, called UnitOfOrder.
WLMessageProducer messageProducer = (WLMessageProducer)session.createProducer(destination);
messageProducer.setUnitOfOrder(processInstance + "");

This workaround could be useful to people working on weblogic.