Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Pre-query flush seems not to flush all deletions in the correct order

Hi Chris,
thank you for your help.

Actually, all the mentioned code is executed within the same transactional method body. No data change is performed before.
firstCollection is obtained directly from first.getFirstCollection().
Between this call and the removal of first there are only other getters calls (which return other related entities that are not modified):
first.getFoo()
firstCollection.getBar()
first.getSomethingElse()
Then, after the deletion of second, and before the query, there's nothing.

The First entity is certainly not referenced by Second, nor by any remove-cascaded entity related to Second (it was an explicit design choice).
In the actual code I'm using Spring Data JPA to perform deletions and queries, but I don't think it should matter.

What I may try to do is to clear the reference between first and second before applying deletions, something like:
Second second = first.getSecond();
first.setSecond(null);
entityManager.remove(first);
entityManager.remove(second);

but it's a shot in the dark. Also, I'm not sure what the "lesson learnt" should be, in order to avoid this problem in the future...

Thanks again,
Mauro

Il 01/03/2016 19:48, christopher delahunt ha scritto:
Hello Mauro,

Is there anything else that might reference the first instance?  Could the firstCollection.getFirsts().remove(first) change be being done on an unmanaged instance so that the FirstCollection instance still references the first instance in the context?

This sometimes happens if you have something left in your object model still referencing the first instance with a relationship marked cascade remove or cascade persist, causing the traversal of the object model to 'undo' the remove call.  This may be inconsistent due to lazily fetched relationships, and how the traversal of the model discovers unmanaged instances.

Best Regards,
Chris







On 01/03/2016 12:08 PM, Mauro Molinari wrote:
Hello,
I have the following problem that puzzles me.

I have an entity, let's call it First, which references another entity, let's call it Second.

The relationship is this:

@Entity
public class First {
  // ...
  @OneToOne(
            cascade = { CascadeType.DETACH, CascadeType.PERSIST,
                    CascadeType.REFRESH },
            fetch = FetchType.LAZY,
            optional = false,
            orphanRemoval = false)
    private Second second;
}

The relationship is unidirectional, i.e. there's no @OneToOne relationship mapped in Second towards First.

First also has a @ManyToOne relationship towards a FirstCollection entity. I don't think it should matter at all, but I say it for completeness.

Then I have some code that takes a First instance (let's call it "first") and does some things like:

FirstCollection firstCollection = first.getFirstCollection();
// do some read-only operations on first
// remove first from the FirstCollection related entities
firstCollection.getFirsts().remove(first);
// delete first
entityManager.remove(first);
// delete the related second instance
entityManager.remove(first.getSecond());
// perform a read query on an entity related to first

When the last step is executed, a flush before the execution of the read query is performed; I see something like this in the stack trace:
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:879)
	at org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush(QueryImpl.java:967)
	at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:207)

The problem is that this lfush seems to perform the deletion of second (together with some of its cascaded deleted entities) BEFORE the deletion of First. I mean, the log shows a call to DELETE on the Second table, but no previous delete on the First table. This causes a foreign key constraint failure.

This seems to happen only sometimes. My question is:
  • how is it possible? I'm calling remove on First before calling remove on Second!
  • how to avoid this problem?

Thanks in advance,
Mauro



_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users



_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users


Back to the top