We have a usecase where a process have a servicetask that does some logic and sets a few variables. After the task if the result is “not ok” the flow will go to an eventgateway where we have a conditional intermediate event (and a timer as backup). The conditional is checking if a boolean variable is true. The update to the variable is triggered from an external source and might be at anytime during, or Before, the processinstance lifetime, this is why we arent using a message Catch as the signal might come Before we reach the eventgateway.
Our problem is that if the process is executing the servicetask when we get the externalsignal and try to update the variable via java api, we will get an optimisticLockingException and the servicetask will rollback and do a retry, this is not optimal in our case. Is there any way to work around this?
I had also experienced this. Does the service task modify the same variable as external event?
The question is - did you try the approach with subprocess? Maybe it will do the work with receiving the external signal/event before you finish service task.
Hello @JarlSeverin,
Indeed that is expected behavior here. Camunda uses an OptimisticLocking approach so that if two threads try to update a process instance (in your case the process variable update thread and the service task thread) the first will win and the second will fail. More info here: https://docs.camunda.org/manual/7.11/user-guide/process-engine/transactions-in-processes/#optimistic-locking
In order to avoid that you could ask the engine via Java-Api if that particular process instance is still executing the service task or not, depending on that result you can update the variable or you will have to wait.
//this will be your friend than
runtimeService.getActiveActivityIds(processInstanceId);
Best, McAlm
Thank you @McAlm !
This was what I suspected but I was hoping I read the documentation wrong. Usually shouldnt be to much of an issue but the service task calls a webservice that due to legal reasons isn’t idempotent and can’t be compensated so retries from optimisticLocks kinda messed with us.
I didn’t even consider the activeIds function, still too new I guess, ended up doing a work around where the service task set a variable to a specific value when it finished and checked if that value was set before trying to update from the external source. Didn’t like that solution so Went with a message intermediate Catch instead of conditional.
You live and learn.
It did at first modify the same variable. I removed that so only the external source modified that variable but still got the same result.