Race condition prevents conditional event from triggering

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