Hi, I am facing StaleObjectExceptions with heavy load in the following scenario. - Dynamic Fork (N child tokens are created) - For each child token there is a State and and task node - Each State has an action handler on node-enter event which calls async WS. When WS operation is finished, the callback is made (token is signalled). Note: No node or action handler is declared as async or exclusive. Exception: | org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): | [org.jbpm.graph.exe.Token#204] | As read on this topic: anonymous wrote : | The stale object exceptions can be avoided by not assuming that the token cannot change through graph execution. | If I understand this correctly, this means by to introduce pessimistic locking. If so, how? - by calling lockProcessInstance method in JbpmContext or in some other way Or, should I treat StaleObjectState as normal thing and according to Tom, - http://jira.jboss.com/jira/browse/JBPM-995 anonymous wrote : | When running in a cluster, jBPM synchronizes on the database. By default with optimistic locking. This means that each operation is performed in a transaction. And if at the end a collision is detected, then the transaction is rolled back and has to be handled. E.g. by a retry. So optimistic locking exceptions are usually part of the normal operation. | implement retry logic in callback methods? Thanks for clarifications Milan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145645#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...