What's the best practice to set camunda:Exclusive=true & camunda:asyncBefore="true"?

I would like to configure async behaviour in activities & parallel gateway to execute concurrently using camunda:Exclusive & camunda:asyncBefore properties.

parallelgateway-async.bpmn (6.1 KB)

Below are the scenarios:

  1. Fork GW: When forking the execution flow is it necessary to mark the parallel gateway as camunda:asyncBefore=“true” & camunda:Exclusive=“true” ? Is these property required in fork gw if it has multiple incoming sequences?

  2. Task A & Task B: Both activities are marked as camunda:asyncBefore=“true” & camunda:Exclusive=“true”, with parallel gateway, both tasks will be executed in parallel or sequential? Note both tasks are after parallel gateway and both tasks are marked as camunda:Exclusive=“true”. What’s the expected behaviour in execution?

  3. Task A & Task B: Do I need to set camunda:Exclusive=“false” in service tasks to achieve concurrency along with camunda:asyncBefore=“true”?

  4. Task A & Task B: What will be the behaviour if Task A(camunda:Exclusive=“true”) and Task A(camunda:Exclusive=“false”)? In this case parallel join gateway need to marked as camunda:Exclusive=“true”?

  5. Join GW: When synchronizing the executions from Task A & Task B, i have marked the parallel gateway as camunda:asyncBefore=“true” & camunda:Exclusive=“true” to avoid Optimistic locking exception. What is the behaviour if the complete process definition is synchronous execution(camunda:asyncBefore|After=“false”), will the optimistic locking exception will throw in the parallel join?

1 Like

Hi @aravindhrs,

regarding your questions, it sems that the missing information about the exclusive flag can be found here: The Job Executor | docs.camunda.org.

My opinon to your questions:

There is no need to set asyncBefore or asyncAfter on a forking parallel gateway. It just puts load on the job executor.

The tasks will be picked up in separated job acquisitions. That may not be real sequential execution (depending on the job executor configuration and one job runs significantly longer than the other), but the jobs are started one after the other.

Yes. But if both services write the same process variable or they join without further asyncAfter on the tasks or asyncBefore on the joining gateway, you may run into an OptimisticLockingException.

I would assume that it is the same having both marked as exclusive (in case of two parallel tasks). It may change if you have more than two tasks and more than one maked as exclusive=false

No, as the state of the process is held in memeory and commited to the database at the end of the process instance, you won’t see a OptimisticLockingException but a sequential execution of the services.

Hope this helps, Ingo

@Ingo_Richtsmeier, Both Parallel Tasks are async continuations, then Task A is marked as camunda:Exclusive=“true” and Task B is marked as camunda:Exclusive=“false”.

So in this scenario, tasks are executed in sequentially and the property async:Before=true is not required to set at parallel join gateway right?

I hope when we mark parallel tasks are exclusive=true, will be picked by the same thread but in different job acquisition. Is that correct?

From the docs,

An exclusive job cannot be performed at the same time as another exclusive job from the same process instance. Consider the process shown in the section above: if the jobs corresponding to the service tasks are treated as exclusive, the job executor will try to avoid that they are executed in parallel.

Hi @aravindhrs,

I don’t know the details exactly, but I would assume that each job acquisition starts a new thread eventally.

Even if the acquisition is always the same thread, the execution will be handed to a new thread from the pool.

Hope this helps, Ingo