кстати говоря, ваш пример прямо в доках есть на объяснения, почему параллельный шлюз делается одним потоком. т.е. по правильному там вообще надо снять транзакции.

Какой пример, можно ссылку, пожалуйста?
По этому вопросу в доках указана необходимость транзакции и ретраев:

Note: one strategy to deal with OptimisticLockingExceptions at a parallel gateway is to configure the gateway to use asynchronous continuations. This way the job executor can be used to retry the gateway until the exception resolves. (https://docs.camunda.org/manual/7.10/user-guide/process-engine/the-job-executor/)

как раз описывают, почему делается в одном потоке, типа иначе у вас будут задачи ретраиться

и это опасно, забронируете несколько раз

However, while this is a perfectly fine solution from the point of view of persistence and consistency, this might not always be desirable behavior at a higher level, especially if the execution has non-transactional side effects, which will not be rolled back by the failing transaction. For instance, if the book concert tickets service does not share the same transaction as the process engine, we might book multiple tickets if we retry the job. That is why jobs of the same process instance are processed exclusively by default.

копия что у вас, так что уберите все транзакции

Спасибо. Ну это немного про другое - про галочку exclusive, она по дефолту true (как и советуют в ссылке).

и будет счастье, если они конечно не нужны.

нет

если не будет транзакции, то это будет одно выполнение и у вас не будет оптимистик ошибки

всегда на шлюзе будет один потом

поток

галочку exclusive - сделает возможным, но не гарантирует

даже больше, шансов еще больше будет

а если транзакций нет, то всегда будет один тред, он вначале одну ветку сделает, потом вторую и получится, что на шлюзе всегда один делает проверку

если ставите транзакцию, то на шлюзе есть шанс, что вместе окажутся два треда и один из них OLE бросит

Да, вы правы. Если транзакции не ставить будет ОК со шлюзом. Но транзакции ведь нужны )
Особенно для внешних запросов,особенно для put/post - для выполнения задачи 1 раз, например, чтобы ретраить и т.д.

Интересно девки пляшут.
В 7.9 есть две таблицы act_ru_task и act_ru_execution соответственно.
У каждой есть свой Foreign Key act_fk_task_procdef (act_ru_task) и act_fk_exe_procdef (act_ru_execution) которые смотрят на таблицу act_re_procdef и на несуществующую колонку proc_def_id_

Это как понимать?

Это у меня так БД восстановило или такое бывает в камунде :)