order of delete get wrong priority when a class reference one that have 3 level hierarchy

test case that simulates the problem.

added patch that solve the problem

discovered that order to call getPriority matters, then put a call to getPriority when map is loading.

Improved patch that executes new tests against derby, mysql and postgresql also. Having said that I'm not sure yet if the changes to LockEngine and ClassMolder deliver correct priority values under all conditions.

I have worked on the priority calculation myself some time ago. At this time I only did some small modifications to the calculation to get a special usecase working. As it always seamed to me that there still is something wrong with this calculation (e.g. cpactf test29 of dependend shows sporadic failures) I will review things in details this time. First looking at the theortical possibilities to define order of database operations.

Sequence of different types of database operations

There are 3 types of database operations to consider: create, update and delete. Of these operations all create operations have to be exectuted first then all updates and last all delete operations.

Sequence of database operations for different entity types

We do not need to take care on sequence of entity types for update operations but for create and delete operations the sequence of entity types is important. E.g. we can not create an entity which refers to another entity that is not persistent yet. Same applies for delete where an entity can not be deleted that is refered by one that is still persistent. Problem to take care of are circulare references like bidirectional 1:1. Having said that circulare references may also involve more than 2 entity types and may also involve multiple entities of the same type. Possible strategies are:

1. Execute operations in the same sequence the user calls methods on Database interface.
2. Calculate sequence of operations based on mapping information once before first operation when all mapping information is available.
3. Calculate sequence of operations based on mapping information for every transaction only for the entity types involved.

Sequence of database operations for entities of the same type

Similar to sequence of database operations of different entity types we only need to care on create and delete. Update can also be ignored here. Circulare references are also a problem for entities of the same type as stated above. Possible strategies are:

1. Execute operations in the same sequence the user calls methods on Database interface.
2. Calculate sequence of operations based on mapping information and entity values for every transaction.

Will continue with analysis of current implementation and problems involved with the different strategies soon.

On my last comment I forgot to take into account one situation that causes problems with the defined sequence of different types of database operations. If a user deletes and creates an entity with the same identity in one transaction, the create executed first will fail with an DuplicateIdentityException. To preven this Castor internally has to execute an update instead of create and delete. Not sure if this already happens or not.

Castor currently calculates priority only for the entities involved in the current transaction and the ones refered by them. It does not take into account the entities that are not involved in the transaction but refer to one it calculated the priority for. The priority values calculated once are keep until virtual maschine is restarted.

If a following transaction also contains entities where priority has not been calculated yet, Castor tries to do so but may fail to find a usefull priority between the already calculated ones. To resolve this problem we have to calculated priority for all entities of a persistence context together before the first transaction starts.

Remaining question is how should priorities been calculated:

• Calculate priority of all entities of an persistence context at once. This is not the case yet.
• For the priority calculation we have to take into account the relations between the entities. That's what current code already does.
• As create and delete operations are automatically propagated to extended entities all entities of a extend hierarchy have to have the same priority. Current implementation calculates different values for entities of an extend hierarchy which is causing the problem reported at this issue.
• Depend declarations should not influence priority. Taking dependencies into account causes the problems reported at CASTOR-2732.

Final patch