-
Feature Request
-
Resolution: Fixed
-
L3 - Default
-
None
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()
This is the controller panel for Smart Panels app
- is related to
-
CAM-6468 CompetingMessageCorrelationTest breaks when running on MySQL/MariaDB with READ_COMMITTED transaction isolation level
-
- Closed
-