Update in-memory collections before dispatching the postRemove event

[mpdude]

Make sure in-memory collections have removed entities unset before the postRemove event is dispatched. This is related to #11098, although by itself probably not going to fix the regression.

Background

When an entity is removed from the database, the UoW also takes care of removing that entity from all in-memory collections. #10763 moved this cleanup and taking snapshots of updated collections to a very late stage during the commit phase, in order to avoid other side effects.

Now, part of the issue in #11098 is that postRemove event listeners will be called at a point where the database-level DELETE has happened (although the transaction has not yet been committed), but the in-memory collections have not yet been updated.

Suggested change

This PR moves the code part that unsets removed entities from in-memory collections and takes collection snapshots (makes collections "clean") from after transaction commit to before the postRemove event. That brings the in-memory update closer to the database-level execution.

In the case of a transaction failure/abort, this leaves us with updated and snapshotted in-memory collections, but no database-level updates. But, at this point, probably things got inconsistent anyways, the EM will be closed and we need not be too worried about the state.

On the other hand, it might not be worth the effort to have clean/consistent collections at postRemove time, since that still leaves us with dirty/inconsistent states during postPersist or postUpdate.

[mpdude]

What happens when we DELETE entities from the database, remove them from in-memory collections as well and then the transaction fails?

Is a transaction failure something that leaves us in an inconsistent state anyway, thus closing the EM?

[beberlei]

Is a transaction failure something that leaves us in an inconsistent state anyway, thus closing the EM?

Yes

[mpdude]

@beberlei

After your comment #11098 (comment), would you say that we should close this PR here and not try to change or fix anything?

This means in-memory collections might still contain removed entities at the time postRemove is called (and additionally, be in a dirty state), whereas the database-level operations have been executed already, but the transation has not been committed yet.

[mpdude]

Closing this.

As of #11146, the documentation is more explicit about the in-memory collection states. For other events, this kind of consistency isn't achieved either, so I am not sure it's worth bothering.