This content has been marked as final.
Show 2 replies
-
1. Re: Update of the root token after one of the sub-tokens in
pojomonkey Mar 5, 2008 4:06 AM (in response to a.grin)"a.grin" wrote:
Is this update (that changes root token) really needed?
The root token is key to the state of the process - seems reasonable that it's state changes as the process is updated.
The stale object exceptions can be avoided by not assuming that the token cannot change through graph execution. -
2. Re: Update of the root token after one of the sub-tokens in
clandestino_bgd Apr 21, 2008 6:59 PM (in response to a.grin)Hi, I am facing StaleObjectExceptions with heavy load in the following scenario.
- Dynamic Fork (N child tokens are created)
- For each child token there is a State and and task node
- Each State has an action handler on node-enter event which calls async WS. When WS operation is finished, the callback is made (token is signalled).
Note: No node or action handler is declared as async or exclusive.
Exception:org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#204]
As read on this topic:
The stale object exceptions can be avoided by not assuming that the token cannot change through graph execution.
If I understand this correctly, this means by to introduce pessimistic locking. If so, how?
- by calling lockProcessInstance method in JbpmContext or in some other way
Or, should I treat StaleObjectState as normal thing and according to Tom,
- http://jira.jboss.com/jira/browse/JBPM-995
When running in a cluster, jBPM synchronizes on the database. By default with optimistic locking. This means that each operation is performed in a transaction. And if at the end a collision is detected, then the transaction is rolled back and has to be handled. E.g. by a retry. So optimistic locking exceptions are usually part of the normal operation.
implement retry logic in callback methods?
Thanks for clarifications
Milan