It seems that I've caused some misunderstanding (or perhaps I don't understand correctly). I do not have process forks and joins in the process defninition, my jBPM just runs one linear process definition. To simplify testing even more, there is just one process instance available a time (process id = 1). The problem is that two threads can interact with the process instance by calling some method on the jBPM core. Since these calls come from completely different directions, they cannot share the execution context (would be a security issue also), they have to rely only on the deterministic behaviour of the jBPM, including defined synchronisation behaviour. As I understand it this problem should also exist in other setups e.g. jBoss SEAM framework with jBPM in the background, where multithreaded jBPM access occurs from different tomcat-webserver threads, but since these frameworks are comparatively slow, time-race conditions with vulnerable interval of 1-10ms or even less will not occur frequently. Perhaps the central question is: Is it allowed to access jBPM methods or objects from two different threads or do I have to build a "synchronized" cage around the whole jBPM to make sure that only one request is executed a time. (Still I'm not sure if this would really solve it since the jBPM includes timers which I guess are implemented as separate threads that could also cause the time-raze conditions). BTW: If useful, I could try to setup a system with full persistence, but I guess that the problem won't be solved that way (unless the desynchronisation is due to broken lock handling in the underlying hibernate code or the in-memory database implementation). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025457#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...