Our team has been evaluating jBPM as the main flow control platform, and this is literally show stopper. Some threads and doc suggested to set isolation level to READ_COMITTED, but I don't think it can solve the issue. When parallel nodes enter into Join node, Join.execute must be executed serialized fashion to check all parallel node status to decide to exit the join. The issue seems like that Hibernate is treating Token object in optimistic locking fashion even in Join.execute method. But what we need in the Join scenario is pessimistic locking, because join will be executed by multiple thread possibly in different JVM, so database level parent Token record level locking is required. Is it possible to use pessimistic locking only in Join.execute()? Here is waht I tried with limited Hibernate knowledge, but all didn't work. In execute method in Join node, when it call session.lock(parentToken, LockMode.FORCE), hibernate seems like incrementing version (why for locking???), and same operation to the same object in another thread throw StaleObjectStateException. This is basic feature we need for concurrent operation, and very easy to implement with SQL based programming with "select for update". I tried to LockMode.UPGRADE too, but the result was same. So, I tried to called "select for update" against parent Token record instead of using session.lock(), and this operation worked as I expected, but when committing transaction on JbpmContext.close(), later thread still throw StaleObjectStateException. OK, then I load object after getting lock (after select for update) by session.load(parentToken.getId(), Token.class, LockMode.UPGRADE), but surprisingly the parentToken object returned still had old version, even DB record was committed and version was incremented. Am I doing something wrong? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136872#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...