Hello my friend!
Yes, a more appropriate modeling will probably solve your problem with OptimisticLocking.
This concurrency error in Camunda can happen in several situations, which we must be careful about when modeling our processes…
A case that I saw in your modeling, and that may be generating this error, is that you have a total of 3 message events… one of which is a start event… this may cause conflicts if they are triggered simultaneously… and perhaps if you receive a message event at the same time as your timer is triggered…
Another thing that could conflict, but to be sure you can only see the code… is that if you update the same variables at the same time in 2 different places, there will be a conflict… for example, if when triggering the start message event you update a variable called “statusProcess” with the value “PROCESS_STARTED”… and at the same time you updated the variable “statusProcess” with the value “PAYMENT_FAILURE” in another place of the same process, you will have an optimisticLocking.
Below I will list some cases that can generate this error so that you can be careful and think better when modeling:
Completing a User Task simultaneously
If two or more users try to complete the same task at the same time, a conflict may occur. Only one of them will be able to, and the others will encounter an Optimistic Locking error.
Concurrent executions in parallel processes
In processes with parallel activities through a parallel gateway, two executions may try to update the same process instance simultaneously. For example, if both executions try to complete the same subprocess or task.
Timers or automatic events firing simultaneously
If there are multiple timers or automatic events firing at the same time for the same process instance, this may cause concurrent attempts to update the same entity in the Camunda database.
Concurrent updates of process variables
When different executions try to update process variables at the same time, the process version may not match and result in an optimistic locking error.
Transaction Compensation
When compensating for failed activities, if multiple transactions attempt to modify the same process instance, this may cause an optimistic locking error.
Event Instances in Subprocesses
When event subprocesses attempt to access or modify the same process instance, the database may detect a conflicting version.
Conflict between listeners or event handlers
Listeners or event handlers that fire simultaneously may attempt to modify data in a context that has already been modified by another execution, leading to an error.
I hope this helps!
William Robert Alves