[jboss-user] [JBoss jBPM] - StaleObjectStateException in a Fork with states

Hi, I'm working a jBPM implementation with the following characteristics: 1) All calls go to external systems, so we use states for modeling the different steps. 2) We might be using forks in our processes, which thus contain states. 3) The external systems store their reply in a variable attached to a token. Without the usage of forks, jBPM works fine. I've been creating some tests to simulate the behaviour of our backend systems by using various threads. Whenever two or more threads within a fork try to signal their respective token at the same time, the second thread throws a hibernate StateObjectStateException when calling JbpmContext.close(). To signal jBPM to continue processing of a state from the external system (simulated by the thread) we use the following code: | JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(); | try { | ProcessInstance processInstance = jbpmContext.getProcessInstance(callInfo.getProcessid()); | Token token = jbpmContext.getTokenForUpdate(callInfo.getTokenid()); | token.setProcessInstance(processInstance); | processInstance.getContextInstance().addVariables(contextData,token); | | token.signal(); | } finally { | jbpmContext.close(); | } | I have to do token.setProcessInstance(), as the process instance == null when calling getTokenForUpdate(), which results in a NPE on token.signal(). I've been looking through mailing lists, documentation and Google to find any info about this problem. Unfortunately to no avail. I've got the following questions: 1) Is my process instance/token retrieval code correct? The jBPM examples which some with the source only contain a quick-and-dirty solution? 2) Should I take care of synchronization myself or is jBPM supposed to handle this (as I expect) and have I run into a bug? Thanks for your time. Jeroen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131342#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...