Unexpected parallel optimistic locking exception

Camunda 7 Topics Discussion & Questions
1

Hi,

I came across an unexpected optimistic locking exception with parallel execution. In a test process, I can use a fork and join, asynchronous, non exclusive execution and the parallelism works as expected.

However, if I create a process variable in each of the parallel flows, I get an optimistic locking exception. Its as if setting independent variables somehow binds the executions together. This is unexpected and leads to some interesting consequence in terms of repeating activities.

Is this a bug?

Please find attached a simple scripted process. Note this has the addition of some async noOps to really reinforce the point.

regards

Rob
Parallel_Test.bpmn (17.2 KB)

2

Hey @Webcyberrob,

can you please state which Camunda version you are using?

Best,
Johannes

3

This was latest 7.6 Alpha5 release…

4

Hey @Webcyberrob,

how the variables are created? Which method do you use?(setVariable or setVariableLocal) Is the variable name different?

Greetings,
Chris

5

Hi Chris,

Just using groovy script tasks with execution.setVariable(“name”, “value”)

regards

Rob

6

Hey @Webcyberrob,

in general setVariable creates a variable on the process instance level, to create local variables use setVariableLocal.

Greetings,
Chris

7

So I think what yiu are saying may be;

SetVariable is operating at process scope and thus there is an optimistic locking exception because there is only one top level process scope.

If I use setVariableLocal, its in the current local execution and thus isolated.

regards

Rob

8

Right, that is what I meant.

Best regards,
Chris

9

Hey Rob,

do you set any variable when you start the process? Does the behavior change if you do so?

I’m asking because ExecutionEntity has a field cachedEntityState that is also reflected in a database attribute. This field is a bitmap that encodes if an execution has variables, event subscriptions, jobs, etc. This is an optimization to avoid certain database queries. However, the impact is that setting the first variable will flip a bit in this map and therefore, two transactions setting two (different) variables in parallel may result in OptimisticLockingException.

Cheers,
Thorben

10

Hi Thorben,
No variable is set at the start. So it seems there is consequence to non exclusive parallel execution. As long as you dont set process level variables its fine. However to propagate up from local to process scope could be tricky…

regards

Rob

11

Hey @Webcyberrob,

I have some further questions to this.
Does the variables have the same name and on which Task, of your given process, do you set the variable?

Greets,
Chris

12

Hi Chris,

two different variable names, each one set on a different path. (Ive attached a very simple minimal example in the original post - its classless so easy to deploy if you want to play…)

regards

Rob

13

Hey Rob,

the workaround would be setting an initial dummy variable.

Cheers,
Thorben

14

Hi Thorben,

Yes if I create the process variables before the parallel split and update them during the parallel split, there is no optimistic locking exception.

regards

Rob

15

Hi Rob, Thorben, Chris,

Thanks for the elaboration. My issue is now solved. So lots of credits to you.

Actually I can set any variable at process level to get this working. It does not need to be the same variables that are set during execution. A thing not to overlook, is that the joining gateway must be set to exclusive, otherwise it sometimes still fails with the optimistic lock exception when testing with multiple (50) test processes at the same time. With the exclusive lock all tests run fine so far.

Cheers,
Patrick

1 Like
16