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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...