as i see it, it works/fails like this: 1a. thread 1 opens a jbpmContext and a process instance 1b. thread 2 opens a jbpmContext and the same process instance 2a. thread 1 passes data to the process instance and gives a signal() 2b. thread 2 also passes data to the process instance and gives a signal() 3a. thread 1 processes the signal 3b. thread 2 processes the signal ---now tatata, the problem occurs--- 4a. thread 1 closes the jbpmContext, this causes the jbpm-engine to commit() the changed processInstance to the database -> OK 4.b thread 2 closes the jbpmContext, this causes the jbpm-engine to commit() the chanced processInstance to the database; commit() fails, because the processInstance on the database is different than it was when it was loaded; StaleObjectStateException is thrown AND CAUGHT by the jbpm-engine -> BAD, because the caller does not notice; data is lost, no retry can be scheduled
-> in my opinion the solution could be a method to tell, when optimistic locking failed to be able to retry. that's what i tried to do in my code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163497#4163497 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163497 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
