JBossDeveloper

another thing to try (keep in mind, I do not see them as solutions!!!) is to put a 'lockmode=pessimistic' attribute on the join node.

And it is indeed the parentNode that is locked, so the fork.

And the default lock is 'FORCE' which is identical to 'UPDATE' (for which 'pessimistic' in jbpm is a synonym.

UPGRADE_NOWAIT is another oracle specific one, just not sure (and no time to find out) what the exact difference is.

Btw, could you try to make the transition to the tasknode the first one? It is not realy deterministic, the order in which they are processed, but I'm curious if it makes a difference at all if one of the transitions has gone to a persistent node before the others are processed. The order is my best guess to be able to achieve this

btw, the join code snippet I saw from you for the join is *not* jbpm 3.3!!! it is older. Or did you copy the small code snippet from the jira issue? If that is the only difference, there is no problem. Othewise please make sure the correct source is used otherwise we might be hunting ghosts.

I've made another test with a stripped version of your process. I've removed the decision handlers, and made a direct transition from fork to join in one of the branches.

This is the result:

HSQLDB: 3.2.2: OK, 3.2.3: OK
Oracle: 3.2.2: FAILED, 3.2.3: OK
Postgres: 3.2.2: FAILED, 3.2.3: OK

Is raises the question wether jbpm is the right choice for enterprise software??[/qupte]

A valid one (but it is... I can assure you it is used in big companies in very important environments), and I already inquired with 'QA' people about the status of getting access to an oracle database for the QA cycle. The response I got was that they are already working on it. Keep an eye on http://www.jboss.org/community/docs/DOC-12860.

We also ran into some other problems with the jbpm console and hot process deployment from eclipse when running on a oracle database.
We can't start process instances from the console and hot deployment is not possible when using oracle. When running hsqldb these things work ok.

Can you elaborate on this?

To finish up on my tests from yesterday, removing the flush() in the Join re-introduced the failure on the direct link from fork to join:

HSQLDB: 3.2.2: OK, 3.2.3: OK, 3.3.0: OK
Oracle: 3.2.2: FAILED, 3.2.3: OK, 3.3.0: FAILED
Postgres: 3.2.2: FAILED, 3.2.3: OK, 3.3.0: FAILED

Martin,

I did a similar test with 3.3.0 and run it against HSQLDB, H2 and mysql with and without the flush added. They run fine.... strange... can you post your unit test so we are sure we use the same test?

if I only had a unit test... sigh... the lack of a proper test is probably the reason why the failure was reintroduced in 3.3.0.

I'm pretty convinced this issue only shows on certain dbs, such as Oracle and Postgres. I can give it another try on MySQL, too (and then write a proper test ;-) )

Martin... I found a similarity.... Oracle and Postgress use sequences, mysql, h2 and hsqldb use auto-increment like id's. I've seen that postgress can also support auto-increment if the int8 is changed to 'serial', see http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL

hibernate does seem to support this: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1675

You have to change 'native' to 'identity' then in the Node.hbm.xml besides changing the sql. Maybe it is worth a try (besides trying with the flush added)

I have a unit test

package org.jbpm.graph.node;

import org.hibernate.LockMode;
import org.jbpm.db.AbstractDbTestCase;
import org.jbpm.graph.def.ProcessDefinition;
import org.jbpm.graph.exe.ExecutionContext;
import org.jbpm.graph.exe.ProcessInstance;

public class StaleObjectExceptionJoinTest extends AbstractDbTestCase {

 public void testDirectTransitionsToJoin() {
 ProcessDefinition processDefinition = ProcessDefinition
 .parseXmlString("<process-definition name='"
 + getName()
 + "'>"
 + " <start-state name='start'>"
 + " <transition name='fromStartToFork' to='fork'/>"
 + " </start-state>"
 + " <fork name='fork'>" // the default
 //+ " <fork name='fork' async='true'>" // Async sometimes solves things that should not be a problem
 + " <transition name='fromForkToDecide1' to='decide1'/>"
 + " <transition name='fromForkToDecide2' to='decide2'/>"
 + " <transition name='fromForkToState' to='state'/>"
 + " </fork>"
 + " <decision name='decide1'>"
 + " <handler class='org.jbpm.graph.node.StaleObjectExceptionJoinTest$Decision1'/>"
 + " <transition name='fromDecide1ToJoin' to='join'/>"
 + " </decision>"
 + " <decision name='decide2'>"
 + " <handler class='org.jbpm.graph.node.StaleObjectExceptionJoinTest$Decision2'/>"
 + " <transition name='fromDecide2ToJoin' to='join'/>"
 + " </decision>"
 + " <state name='state'>"
 + " <transition name='fromStateToJoin' to='join'/>"
 + " </state>"
 + " <join name='join'>" /* the default */
 //+ " <join name='join' lock='"+ LockMode.UPGRADE.toString() + "'>" /* same as 'pessimistic' */
 //+ " <join name='join' lock='"+ LockMode.UPGRADE_NOWAIT.toString() + "'>" /* something for Oracle */
 //+ " <join name='join' lock='"+ LockMode.READ.toString() + "'>" /*... */
 //+ " <join name='join' lock='"+ LockMode.WRITE.toString() + "'>" /*... */
 + " <transition name='fromJoinToEnd' to='end'/>"
 + " </join>"
 + " <end name='end'/>"
 + "</process-definition>");

 jbpmContext.deployProcessDefinition(processDefinition);
 long processDefinitionId = processDefinition.getId();
 newTransaction();

 try {
 processDefinition = graphSession
 .findLatestProcessDefinition(getName());
 ProcessInstance pi = jbpmContext.newProcessInstance(getName());
 assertEquals("start", pi.getRootToken().getNode().getName());
 pi.signal();
 assertEquals("fork", pi.getRootToken().getNode().getName());
 assertEquals("join", pi.findToken("/fromForkToDecide1").getNode().getName());
 assertEquals("join", pi.findToken("/fromForkToDecide2").getNode().getName());
 assertEquals("state", pi.findToken("/fromForkToState").getNode().getName());

 } finally {
 newTransaction();
 graphSession.deleteProcessDefinition(processDefinitionId);
 }

 }

 public static class Decision1 implements DecisionHandler {
 private static final long serialVersionUID = 1L;

 public String decide(ExecutionContext executionContext) {
 return "fromDecide1ToJoin";
 }
 }

 public static class Decision2 implements DecisionHandler {
 private static final long serialVersionUID = 1L;

 public String decide(ExecutionContext executionContext) {
 return "fromDecide2ToJoin";
 }
 }

}

H2 is cooooooooooool..... it has an oracle and postgress compatible mode.... If you use it's own H2 driver, but point to a Oracle dialect and state in the connect string the mode is oracle, like:

 <!-- hibernate dialect -->

 <property name="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</property>


 <!-- JDBC connection properties (begin) -->
 <property name="hibernate.connection.driver_class">org.h2.Driver</property>
 <property name="hibernate.connection.url">jdbc:h2:~/jbpm;MVCC=TRUE;MODE=Oracle
 </property>
 <property name="hibernate.connection.username">sa</property>
 <property name="hibernate.connection.password"></property>
 <!-- JDBC connection properties (end) -->