Context:

• If multiple threads correlate multiple messages to the same subscription concurrently, all except one fail with optimistic locking.
• This is OK and one of the fundamental design decisions on the process engine
• The behavior is undesirable if between the message event and the transaction boundary (where OptimisticLockingException occurs) user code with non-transactional side effects is executed.
• The default answer to this would be to place the transaction boundary before the point where the user code is invoked
• But: this is undesirable in case the result of the user code invocation is required synchronously by the code executing the correlation.

==

AT:

• Optionally, I can correlate a message "exclusively" ensuring that a pessimistic lock is acquired on the event subscription, before the waiting execution is signalled

==

Api Idea: runtimeService.createMessageCorrelation()...correlateExclusively()