[jboss-user] [JBoss jBPM] - Re: does this design make sense?

[dOoMi]

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