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

[dOoMi]

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#4163464

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163464