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
|