[jboss-user] [jBPM Users] - Hibernate, Sessions, and Sync - Oh my!

[michaelholtzman]

Greetings -

We are plagued with StaleObjectStateExceptions that I have been unable to resolve. We are running jBPM (derived from version 3.1.2) in an application which launches and manages our workflows and also executes commands targetting specific workflow instances (for example, a signal from our main application, an external system wrt the jBPM app).

We have a number of custom nodes that call out to our system and enter a wait state. Our system processes the request and sends back a command to the jbpm application. The command will include the process instance and token that made the request, and possibly data that will be saved in jbpm instance variables.

Our custom nodes use the JbpmContext attached to the current ExecutionContext. The 'out of band' command processing creates a new JbpmContext from a singleton JbpmConfiguration, loads the specified token by id and modifies it, then saves and closes the JbpmContext.

In general this works great, but I have one case that consistently causes SOSE's:

A custom node (Wait) creates a timer with a 10 second due date. When the timer fires, it transitions to a custom node (Script) that messages our system and goes into a wait state. Our system responds with a 'Results' command that essentially does this:


  | gProcessInstance = jbpmContext.loadProcessInstance(gProcessInstanceId);
  | if (gProcessInstance == null) 
  |    throw new Exception("Unable to load  process instance id " + gProcessInstanceId);
  | 
  | if (gTokenId > 0) {
  |    gToken = jbpmContext.loadToken(gTokenId);
  | } else {
  |    gToken = gProcessInstance.getRootToken();
  | }
  | 
  | // Get new JbpmContext from static configuration
  | jbpmContext = Manager.jbpmConfiguration.createJbpmContext();
  | try {
  |    // Set some instance variables
  |    ...
  | 
  |    // Save and close the jbpmContext
  |    jbpmContext.save(gToken);
  | } catch (Exception e) {
  |    ...
  | } finally {
  |    jbpmContext.close();
  | }
  | 

Usually this works correctly, advancing the token from the 'Script' node to the next node in the process. However, sometimes the signal advances the token from the 'Wait' node -- the token's previous node. The next execution of jbpmContext.close() throws the SOSE.

My theory du jour is that somehow the transition in the workflow from 'Wait' to 'Script' has not been committed at the time the 'Result' command arrives, so that the loadToken() call is getting  the state of the token before it moved to the 'Script' node and the Token.getNode() is returning the wrong node as the source of the transition.

I have tried adding 

  | jbpmContext.save(token);
  | jbpmContext.getSession().flush();
  | 
when the 'Wait' and 'Script' nodes go into their respective wait states, as well as inserting 

  | jbpmContext.getSession().refresh(gToken)'
  | 
after loading the token, but the problem persists.

Any ideas?

Thanx.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257134#4257134

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