Thanks for the jira info JBPM-1072. I have read through it. First of all, I would like to confirm my understanding is correct. jBPM polls JOB table entry by JobExecutorThread and execute the job by the same JobExecutorThread object. Since each thread has unique name and save it into job record to lock it, the job will be executed only once by one thread. And this jira concluded the cause of SOSE is that each thread has the same name, that's why the same executed more than one thread that causing conflict. But what I am facing is little bit different. The SOSE is happening when it's locking parent token object that is shared by many job entries if they are under the same "fork" node. Since each thread for each job entry of the same parent token will call session.lock() against the same parent token object in optimistic locking fashion, the SOSE will be thrown as java code says. I have downloaded latest version of Join.java, that has sussion.flush() right before session.lock() is called. But it still has the SOSE on the method invocation of the second node's execution under the fork. I have found the work around for this issue with JDBC "select for update" and session.refresh(parentToken) instead of calling session.flush() and session.lock(parentToken). This implementation is very simple, and works perfectly even jobs run on the different JVM under clustered environment. Is it possible to ask jBPM team to review my implementation? Tak View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137238#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...