I observed that the EntityDeleteAction uses an outdated version to delete a child entity of a parent-child relationship when using hibernate-generated versioning on the childs. The behaviour was observed with Hibernate 3.3.2 GA.

The scenario is the following:
An instance p1 of the parent class P is loaded from the database together with the childs c1, c2 from the child class C. The child c1 references c2 via a foreign key. After loading the childs c1 and c2 are removed from its parent (delete-orphan is enabled) and a new child c3 is added as a child of p1. The parent p1 is persisted (persist cascades to childs) and the insert action for c3 and delete actions for c1 and c2 are queued. After that the session is flushed. During flush hibernate will queue an update for child c1 to remove the foreign key reference to c2. But this update causes the verion of c1 to be incremented. But the version in the EntityDeleteAction for c1 is held in a final field. Hence the EntityDeleteAction for c1 will use the outdated version in the final field. This will cause a optimistic locking failure.

My question is if this really is a bug or is there some configuration problem? The problem does not occur when using database generated versions. But I do not want to use database generated versions because of the performance impact.

The update is not the problem as this must be executed to be able to safely delete c2.

The described problem looks very similar to what was described in viewtopic.php?f=1&t=953766&start=0
But I do not want to use the proposed workaround in that thread.

Thanks for any help

Hibernate seems too smart for me.

The problem is that we use triggers that update the versions, if the updated row contains the same version (this is for interoperability with legacy applications operating on the same schema, which themself do not use optimistic locking). Hibernate will not increment versions for deleted entities as the entity will be deleted anyway at the end of the session. Of course this approach will work, but I think it is questionable why this behaviour is not optional. Particularly because using database generated versions also maintain an "expected version" when the actual delete statement is generated.

The solution we choose is to maintain a session variable that tells the trigger if the version should be incremented if the version of the updated row is the same as before the update.