Re: [eclipselink-users] Pre-query flush seems not to flush all deletions

[Mauro Molinari <mauromol@xxxxxxxxxx>]

Il 02/03/2016 15:59, christopher delahunt ha scritto:

I mistyped when I wrote cascade remove - I meant to write cascade merge or cascade persist.  Any references to 'first' could be causing it to be resurrected, not just ones from the 'second' instance's object graph.  I also noticed you are using cascade refresh and lazy relationships - refresh of the referenced entity over a lazy reference will be delayed until it is accessed, potentially wiping out changes made so far.  Something that causes a refresh of firstCollection for instance might get triggered after the remove call but before the flush, and cause firstCollection to still reference first and cause its resurrection in the persistence unit.  I would detail all the references in your object model to the 'first' class and check that one isn't interfering.

Hi Chris,
just an update. Removing the cascade=REFRESH metadata on the entities referring to First did not solve the problem, actually.
As a last attempt I tried to exchange the order of these two statements, from:
firstCollection.getFirsts().remove(first);
entityManager.remove(first);

to:
entityManager.remove(first);
firstCollection.getFirsts().remove(first);

suspecting that  the removal from the list (which should be mapped to an UPDATE statement on the first instance, since First owns the relationship) might shadow and override the DELETE statement in some way. But this did not solve the problem either.

So, I resigned myself to perform the double flush, immediately before and immediately after the first instance removal:

entityManager.flush();
entityManager.remove(first);
entityManager.flush();

I don't like this at all, but I think I'm really out of ideas now. I really suspect it's an EclipseLink bug, but I really don't know how I could extract a test case for this. As I said, it does not happen always, but often, and I could reproduce it locally just once.

Mauro