-
Bug Report
-
Resolution: Unresolved
-
L3 - Default
-
None
-
7.2.0, 7.3.0, 7.4.0-alpha1
-
None
The configuration option "isDbEntityCacheReuseEnabled" makes the engine share an entity cache between multiple transactions of job execution. However, it also shares it with the transaction that handles the failure of job execution, where the current cache state is not valid anymore, because a previous transaction has been rolled back.
Example:
- see attached diagram
- Task A is async
- Task C fails on execution
When the job is executed the first time, the executing transaction fails (due to Task C), however the transaction handling the failed job flushes all the changes made by the previous transaction since it shares the entity cache. This results in:
- Unwanted history entries (here: activity instances for Task A, B, and C although the transaction was rolled back)
- Inconsistent execution state (here: the execution is set to Task C by the failed job handling transaction, thus B is skipped when the job is executed the next time; for the same reason, the failed job command is not able to read the configuration for Task A)
By default, the option isDbEntityCacheReuseEnabled is set to false (which is also the workaround for this problem).
related forum post:
This is the controller panel for Smart Panels app
- is related to
-
-
- Closed
-