Is there any way to disable OptimisticLockingException via any Configuration?

Is there any way to disable OptimisticLockingException via any Configuration (*.xml) or can any one suggest the best way to handle the error?

What would you prefer to happen instead of an OptimisticLockingException been thrown?

I’d like to execute external service tasks (workers via REST) completely in parallel and independent of each other and as fast as possible entering a (joining) parallel gateway no matter what task completes in any order. The tasks should only come to the gateway without OptimisticLockingException.

Currently, I catch that error via sending ExternakTaskFailure catching the same task in the next roundtrip via FetchAndLock and send CompleteTask immediately. That feels a bit like a dirty workaround.

That does indeed sound a bit dirty…
Off hand i would suggest adding an Asynchronous After on the external task. This should have the external task complete without having to deal with the optimistic locking exception (OLE). in this case, if the OLE happens the engine itself will take care of it and will keep trying it until it succeeds.

Thanks for your help. I tried implementing your suggestion narrowing my problem down. And I think it solved my problem. In addition, I figured out that an asyncBefore=true & exclusive=false at the joining gateway fulfills the same purpose as your suggestion. Am I right?

Side question: Does the job executor and its configuration affect my wish to execute everything in parallel as fast as possible and independent of each other? (I left it in default while using Camunda Remote Architecture via REST API). Remember I only use external service tasks that are acquired by workers (that perform e.g. HTTP calls of unknown duration - sometimes up to minutes). My workers work in a multi threaded environment, i.e. for each fetched and locked task a thread is created using my CPU as efficient as possible - hopefully.

Check zeebe instead camunda, for this scenario. Camunda db always will have some locking issue in multi thread environment.

Nah, I’m not sure. Multi-threaded are only my workers. So when I fetch and lock tasks I don’t want e.g. 30 tasks to be executed in the same thread especially when I do long-during HTTP calls. I’d rather like to go with Camunda instead of Zeebe. I already figured out how to avoid OLEs when writing to process variables. Only problem left was OLEs at gateways regarding the ExecutionEntity, but this is now fixed thanks to Niall’s suggestion. Now it’s only about performance.