Race condition prevents conditional event from triggering

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-13762
Reporter	@ThorbenLindhauer
Has restricted visibility comments	true

---

Scenario:

• Process with a conditional event (see attached model, the embedded sub process is important to avoid OLE on the process instance execution)
• Condition is initially not fulfilled
• Transaction 1: Enters conditional event
• Transaction 2: Sets variable that would trigger conditional event
• Transactions 1 and 2 occur in parallel with arbitrary interleaving

Expected behavior:

• Once both transactions have finished, the variable is set and the conditional event has triggered

Current behavior:

• In some situations, both transactions have comitted, the variable is set, but the conditional event has not triggered
• The reason is a race condition in which each transaction does not yet see the effect of the other, but there is no synchronization between them that would detect this problem

Implementation consideration:

• The solution requires synchronization between the two transactions, such that it is guaranteed that one of them always sees the effects of the other before committing

Solution Outline:

• There is a new process engine configuration option called strictSynchronizationForConditionalEvents
• If set to false, the behavior of the process engine does not change (i.e. it works as if this bug is not fixed)
• If set to true, if a process contains a conditional event, the process engine will always synchronize a process instance on the following operations:
  • Any command that sets variables
  • Any command that creates a conditional event subscription (i.e. that enters a conditional event in the BPMN model)
• Technically, the synchronization is implemented as an increment of the revision of the corresponding process instance execution in the ACT*RU*EXECUTION table
• In consequence, the following behavior can be observed
  • Case 1
  • Parallel transaction 1 sets a variable
  • Parallel transaction 2 enters a conditional event
  • Transaction 1 commits first and is successful.
  • Transaction 2 rolls back and fails with OptimisticLockingException
  • Case 2
  • Parallel transaction 1 sets a variable
  • Parallel transaction 2 sets a variable
  • Transaction 1 commits first and is successful.
  • Transaction 2 rolls back and fails with OptimisticLockingException
  • Case 3
  • Parallel transaction 1 enters a conditional event
  • Parallel transaction 2 enters a conditional event
  • Transaction 1 commits first and is successful.
  • Transaction 2 rolls back and fails with OptimisticLockingException
• The default value of the flag is false. This is because this strict synchronization behavior will also affect cases that do not need it (e.g. from above: case 3 and case 2 most of the time) and this bug is rarely encountered in practice
• The documentation of the flag clearly explains for which cases it is relevant, its implications and users are well informed to decide if they should activate it or not

Links:

• is depended on by https://jira.camunda.com/browse/SUPPORT-6035
• is depended on by SUPPORT-23918
• is related to https://jira.camunda.com/browse/CAM-10715

[ThorbenLindhauer]

This comment was imported from JIRA and written by user n5aVr55

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

do you need me to respond or push this?

[ThorbenLindhauer]

This comment was imported from JIRA and written by user PdgBdBD

What is this name?

This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.

---

@Jon Sanchez that might help.  We're stuck with a manual solution for the time being.

[ThorbenLindhauer]

https://github.com/ThorbenLindhauer/camunda-engine-unittest/tree/2593-fix-illustration implements the fix as a process engine plugin and can be tried out to see if it resolves a particular situation and if the drawbacks of the fix are acceptable.