Note that because of the use of the transaction template, hibernate will assume that any staleobject exception coming out of the commit is an error. It will log and throw this exception. Personally I think this is very bad form in a library! :) In a multi-instance environment you will have to manually silence it as these optimistic lock failures are perfectly ok. They are caught and silenced in the core jbpm executor code but of course will not occur because of the delayed commit. e.g. org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.job.ExecuteNode | Job#140392] | at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) | [...] | at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) <== CULPRIT! | [...] | at org.jbpm.SpringExecutorThread.acquireJobs(SpringExecutorThread.java:33) | Please note that the above code does not deal with this problem at all. You will end up with 2 logged errors for every optimistic lock failure in a multi instance environment. The errors should be benign otherwise. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250511#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...