L3 - Default The method DbOperationManager#sortByReferences uses the cached entity state to compute the flush ordering. This need not necessarily reflect the state in the database.
Example:
Assume a persistent execution structure a <- b <- c
In one transaction:
1. remove b such that new tree is a <- c (can happen when concurrency ends and a concurrent parent is removed)
2. Remove a and c
The above-mentioned method now takes into account the relationship from a <- c, so the relation of c to b is ignored and the flushed DELETEs may be ordered incorrectly
When fixing this, please re-add the failing test cases of CAM-3453
This is the controller panel for Smart Panels app
[CAM-3604] Foreign Key Constraint errors due to incorrect flush ordering
This ticket also affects compensation in the cases like in the attached file process1.png:
tx1:
- an event scope execution is created
- the user task is reached
tx2:
- compensation is thrown
- the event scope execution is made a child of the throwing execution (which is now a scope due to
CAM-4285) - compensation completes synchronously
- the event scope execution is removed
On flush of tx2, the error described in this ticket appears because the event scope execution is moved to another parent and deleted in the same transaction.
this behavior also breaks three test cases in our test suite in TransactionSubProcessTest
CAM-4385 is also relevant to this fix since the cached references may become inconsistent as well, when the cache is reused after a failed command.
One additional improvement that I am not going to make right now is that whenever we fetch a persistent object a second time within an ongoing command, we can update the persistent references based on that. This would probably avoid some foreign key exceptions on flush and provoke more optimistic locking exceptions instead that in turn are more user-friendly.
Meaning that these delete operations must be ordered according to their "Db state" and not the state in which they are at the end of the command?