Update of the root token after one of the sub-tokens in the

[a.grin]

Hi,

I have the following scenario:
1. Fork in the process that splits it into 3 branches
2. Each branch has one task. Each task will be assigned to the different user.
3. Each task has only one leaving transition - to join node.
4. One user completes the task. Sub-token advances to the join node.

Database record for the sub-token is updated - ok.
Root token remains on the same node (fork) but is also updated. Only one field changes in the root token record - nextlogindex. It forces also the update of the version field.
Is this update (that changes root token) really needed?
This behaviour creates a problem for the stateful application when several users work with the same process in parallel (each one on his own task in parallel process branch). Hibernate StaleObjectException is very probable.

Thanks,
Andrey.

[pojomonkey]

"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.

[clandestino_bgd]

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