[jbpm-users] [JBoss jBPM] - Re: does this design make sense?

I'm facing the same problem: jBPM swallows the StaleObjectStateException causing the calling code not to notice that the operation failed. I figured out a workaround, but I'm not sure yet, whether it's proper or not. The idea is to do the hibernate-commit() by myself and so be able to receive the StaleObjectStateException in case there was a concurrent update on the process-instance. In this case a retry can be scheduled. | ProcessInstance pi = jbpmContext.loadProcessInstanceForUpdate(id); | | pi.signal("someTransitionIfYouWant"); | | boolean error = false; | | try { | // commit() on hibernate-level | jbpmContext.getSession().getTransaction().commit(); | | } catch (StaleObjectStateException e) { | error = true; | | } finally { | // the tricky part: on the close()-method the jbpmContext tries to commit(), again! | // to avoid irritating error-messages, we need to make the jbpmContext NOT try to commit() | DbPersistenceService dbps = | (DbPersistenceService) jbpmContext.getServices().getPersistenceService(); | | // this can be achieved by pretending that transactions are disabled anyway | dbps.setTransactionEnabled(false); | jbpmContext.getServices().setPersistenceService(dbps); | | // close jbpmContext | jbpmContext.close(); | } | | // handle error if present | if(error){ | // e.g. schedule retry | } | else{ | ... | } | What do you guys think? Any suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163464#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...