[jbpm-users] [jBPM Users] - Hibernate, Sessions, and Sync - Oh my!
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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...