cancel
Showing results for 
Search instead for 
Did you mean: 

Constraint violation by ending a process execution

jaylemur
Champ in-the-making
Champ in-the-making
Hi.

We are actually using the Version 5.10 of Activiti.

We have a Process which starts a subprocess.
This subprocess uses a ServiceTask (Asynchron) which can takes several seconds to execute.
The subprocess  has a boundary Event (Signal) which should cancel the subprocess and starts it again.

Unfortunately we can observe the following behavior :

1) A process instance is started
2) A subprocess instance A is started
3) The ServiceTask A1 is started
4) During the time the ServiceTask A1 is running, the boundary event is signaled.
5) The boundary event start a new instance B of the subprocess
6) The ServiceTask A2 is started
7) Wenn the ServiceTask A1 finishes, it updates some process instances variables.
8 ) Wenn the ServiceTask A2 finishes, it tries to updates the same process instances variables and get an OptimisticLockingException due to the fact that ServiceTaskA1 updated the same variables just before.
9) Due to this OptimisticLockingException, The ServiceTask A2 will come again.
10) In the execution table we have now a "main" execution for the process and two "child" executions for the subprocess,
11) If the condition are fullfilled in order to finish the whole process, we get a ConstraintViolation as Activiti tries to delete a "main" execution together with one child. This fails as it still exists a child execution of the main one.

What's wrong with our process ?

Thanks in advance for any hints.

Cheers,
Patrick Brühlmann
1 REPLY 1

jbarrez
Star Contributor
Star Contributor
hmmm, that is indeed tricky. a way of solving this generically, is to have the service call being executed externally. That is, you send a message to something external, it gets processed there. Your process simply goes further to a wait state. Then when the work is done, you put a message back on some queue (doesn't need to be a queue, can just be a method) that checks if the process is still in the wanted wait state. If so, it triggers, if not it can either wait and try again later or discard it. integrations like camel / spring integration might be suitable here for this kind of logic.