There are a number of failures that are based on outdated process instance state and that are detected on database-level via constraint violations (e.g. foreign key violations or uniqueness violations). The correct way for users to deal with these situations is retrying the interaction (like in cases when OptimisticLockingException is thrown).
Current behavior:
- The process engine throws ProcessEnginePersistenceException. For such exceptions, users cannot distinguish the optimistic locking case from the case where something is seriously broken. Thus, they cannot perform automated retries.
Expected behavior:
- The process engine throws OptimisticLockingException so that users can always catch the exception and retry the interaction.
Example:
- violation of uniqueness constraint of scope and name of variables (i.e. no scope can have the same variable twice)
Basic solution ideas:
- Reordering the flush when there are dependencies between entities (in example 1: currently, the UPDATE of the concurrent execution is performed after the INSERT, so the UPDATE does not trigger OptimisticLockingException. Reversing the order would avoid the constraint violation).
- Catching java.sql.SQLIntegrityConstraintViolationException on INSERT and then re-selecting any foreign-key-referenced entities to check their existance. If they don't exist anymore, throw OptimisticLockingException
This is the controller panel for Smart Panels app
- depends on
-
CAM-8759 Change isolation level to READ-COMMITTED for MySQL containers
-
- Closed
-