Hibernate - A collection with cascade=”all-delete-orphan” was no longer referenced by the owning entity instance

Question

I'm having the following issue when trying to update my entity:

"A collection with cascade=”all-delete-orphan” was no longer referenced by the owning entity instance".

I have a parent entity and it has a Set<...> of some children entities. When I try to update it, I get all the references to be set to this collections and set it.

The following code represents my mapping:

@OneToMany(mappedBy = "parentEntity", fetch = FetchType.EAGER)
@Cascade({ CascadeType.ALL, CascadeType.DELETE_ORPHAN })
public Set<ChildEntity> getChildren() {
    return this.children;
}

I've tried to clean the Set<..> only, according to this: How to "possible" solve the problem but it didn't work.

If you have any ideas, please let me know.

Thanks!

Recitative

@mel3kings, the link you provided is no longer active. – Settlement

try using mutable collections when removing elements. For example don't use something.manyother.remove(other) if manyother is a List<T>. Make manyother Mutable, like ArrayList<T> and use orphanDelete = true – Immerse

There is this bug which looks suspiciously similar: hibernate.atlassian.net/browse/HHH-9940 And the code to reproduce it: github.com/abenneke/sandbox/tree/master/… – Demello

link "How to "possible" solve the problem" no longer available – Nonpareil

'How to "possibly" solve the problem' link in the Internet Archive... – Firstclass

Answer 1

Actually, my problem was about equals and hashcode of my entities. A legacy code can bring a lot of problems, never forget to check it out. All I've done was just keep delete-orphan strategy and correct equals and hashcode.

Recitative

please, an example of a well made equals and hashCode methods? because i have a lot of problems: or i can't update my set or i get a StackOverflow error. i opened a question here: #24737645 . thanks – Tragedienne

Answer 2

Check all of the places where you are assigning something to sonEntities. The link you referenced distinctly points out creating a new HashSet but you can have this error anytime you reassign the set. For example:

public void setChildren(Set<SonEntity> aSet)
{
    this.sonEntities = aSet; //This will override the set that Hibernate is tracking.
}

Usually you want to only "new" the set once in a constructor. Any time you want to add or delete something to the list you have to modify the contents of the list instead of assigning a new list.

To add children:

public void addChild(SonEntity aSon)
{
    this.sonEntities.add(aSon);
}

To remove children:

public void removeChild(SonEntity aSon)
{
    this.sonEntities.remove(aSon);
}

Earwig

Actually, my problem was about equals and hashcode of my entities. A legacy code can bring a lot of problems, never forget to check it out. All I've done was just keep delete-orphan strategy and correct equals and hashcode. – Recitative

I'm glad you solved your problem. equals and hashcode have bitten me a few times with Hibernate. Instead of updating the title of the question with "[Solved]" you should go ahead and post your answer and then mark it as the accepted answer. – Earwig

Thanks, I ran into something similar and turned out my setter for that Set was empty.. – Comenius

yes even on empty lists you get this error. i would not expect that because there are no orphans (the list was empty). – Postmark

Usually you want to only "new" the set once in a constructor. Any time you want to add or delete something to the list you have to modify the contents of the list instead of assigning a new list. Most imp – Pash

thank you, you saved me a lot of time! I was setting new collection in my setter and that was ruining everything, I just followed your advice and changed the logic to filter my list based on passed argument – Bellbird

For anyone else arriving at this in a slightly different way: It still boiled down to accidentally nulling out a list property. It was just that we had done a rename of a property in a class that was being converted to the class that we were about to save. So we wound up just setting that specific property more manually after the conversion. – Rakel

Answer 3

The method:

public void setChildren(Set<SonEntity> aSet) {
    this.sonEntities = aSet;
}

works if the parentEntity is detached and again if we update it.
But if the entity is not detached from per context, (i.e. find and update operations are in the same transaction) the below method works.

public void setChildren(Set<SonEntity> aSet) {
    //this.sonEntities = aSet; //This will override the set that Hibernate is tracking.
    this.sonEntities.clear();
    if (aSet != null) {
        this.sonEntities.addAll(aSet);
    }
}

Outdistance

@Skuld I have a similar problem and I applied your solution (in the setter method I clear the children collection - this.children.clear() - and I added the new children - this.children.addAll(children)). This change didn't fix my problem. I still get the "A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance" exception. Do you have an idea why? Thank you very much! – Biretta

@Biretta Sorry this isn't my answer, I just sorted out the formatting of the answer, the original author (kmmanu) might be able to help you out (or alt you might want to start a new question if your scenario is different to the original question asked here) Good luck – Jackinthebox

This works well, but not so good when the children are contained in a nested hibernate component and the component is made null in it's Entity. Then you get the same error. This is because the owner of the children is the root Entity and not the component that is made null... A such, a component is never allowed to become null, but rather should result in a forward to a destroy() method in the child... At least, I don't know a better solution... It's a kind of collection clear() construction but then on a component through destroy()... – Cymoid

See also this post for more details of above: #4770762 – Cymoid

use this.sonEntities.retainAll(aSet) over sonEntities.clear() because if aSet == this.sonEntities (i.e. the same object) you will clear the set before you add to it! – Telluride

simply brilliant! – Peterson

This is what i needed "this.sonEntities.clear();" thanks @Outdistance – Iguanodon

@Telluride Wouldn't it be more efficient to just check for equality before clearing? i.e. if (aSet == this.sonEntities) { return; } else { this.sonEntities.clear() .... Traversing a Set twice does not look like something one would like to do in a setter... – Artemis

Answer 4

When I read in various places that hibernate didn't like you to assign to a collection, I assumed that the safest thing to do would obviously be to make it final like this:

class User {
  private final Set<Role> roles = new HashSet<>();

public void setRoles(Set<Role> roles) {
  this.roles.retainAll(roles);
  this.roles.addAll(roles);
}
}

However, this doesn't work, and you get the dreaded "no longer referenced" error, which is actually quite misleading in this case.

It turns out that hibernate calls your setRoles method AND it wants its special collection class installed here, and won't accept your collection class. This had me stumped for a LONG time, despite reading all the warnings about not assigning to your collection in your set method.

So I changed to this:

public class User {
  private Set<Role> roles = null;

  public void setRoles(Set<Role> roles) {
  if (this.roles == null) {
    this.roles = roles;
  } else {
    this.roles.retainAll(roles);
   this.roles.addAll(roles);
  }
}
}

So that on the first call, hibernate installs its special class, and on subsequent calls you can use the method yourself without wrecking everything. If you want to use your class as a bean, you probably need a working setter, and this at least seems to work.

Weber

Why are you calling retainAll()? Why not clear() followed by addAll()? – Cymoid

"Why are you calling retainAll()? Why not clear() followed by addAll()?" Good question, I think I was working under the assumption that hibernate would be less likely to see this as a database update if you didn't remove the items before adding them again. But I suspect it doesn't work that way anyway. – Weber

You should use retainAll() over clear() otherwise you may wipe out the roles if you happen to pass in the identical set object. For example: user.setRoles(user.getRoles()) == user.roles.clear() – Telluride

When you set orphanRemoval=true and you creare a record where this collections is null, you also get this error. So: a has oneToMany b with orphanremoval = true. When you create A where B = null, this issue is triggerd. Your solution to initialize and make it final seems the best. – Avant

Thank you! I was initialising my List as List<String> list = new ArrayList<>();. Changing it to List<String> list = null; fixed the problem :) – Arbitrage

Actually, the first code block in your answer works if you just remove the final modifier. This way: (1) When you create an entity with new in your code, the roles will be instance of HashSet, that is totally fine for Hibernate when it persists a new entity. (2) When you update a managed entity, the roles will be instance of managed hibernate proxy, because it will assign it to the field on entity load (because it's not final). (3) When you merge a transient entity, it's also fine. – Bloodstream

Answer 5

I fixed by doing this :

1. clear existing children list so that they are removed from database

parent.getChildren().clear();

2. add the new children list created above to the existing list

parent.getChildren().addAll(children);

Hope this post will help you to resolve the error

Eta

Worked for me....thanks. – Knisley

Alongwith the above code, I also had to modify repository from CrudRepository to JpaRepository and user saveAndFlush() calls. One after removing all and one after adding new ones. – Sisak

Answer 6

I had the same error. The problem for me was, that after saving the entity the mapped collection was still null and when trying to update the entity the exception was thrown. What helped for me: Saving the entity, then make a refresh (collection is no longer null) and then perform the update. Maybe initializing the collection with new ArrayList() or something might help as well.

Wehrmacht

Sending new ArrayList instead of null, worked for me. Thanks – Masculine

Answer 7

I ran into this when updating an entity with a JSON post request. The error occurred when I updated the entity without data about the children, even when there were none. Adding

"children": [],

to the request body solved the problem.

Westernmost

Answer 8

It might be caused by hibernate-enhance-maven-plugin. When I enabled enableLazyInitialization property this exception started on happening on my lazy collection. I'm using hibernate 5.2.17.Final.

Note this two hibernate issues:

• https://hibernate.atlassian.net/browse/HHH-10708
• https://hibernate.atlassian.net/browse/HHH-11459

Shick

still happens using 5.5.7.Final problem occurs when entity to merge is deserialized from a web session, e.g. when merging changes from an jsf front end to the backing service where the merge should take place setting enableLazyInitialization to false solves this error but with the downside to not be able to use the LazyInitialization feature as well which is kind of annoying – Trattoria

Answer 9

All those answers didnt help me, BUT I found another solution.

I had an Entity A containing a List of Entity B. Entity B contained a List of Entity C.

I was trying to update Entity A and B. It worked. But when updating Entity C, I got the mentioned error. In entity B I had an annotation like this:

@OneToMany(mappedBy = "entity_b", cascade = [CascadeType.ALL] , orphanRemoval = true)
var c: List<EntityC>?,

I simply removed orphanRemoval and the update worked.

Egbert

Hi @Egbert now I am not getting above error after removing orphanRemoaval but I am getting new error mentioned below . object references an unsaved transient instance - save the transient instance before flushing – Cauda

@Cauda amazing, glad I could help – Egbert

Yeah, but now you have a completely different behavior. If you remove the annotation, orphans will no longer be removed. That means that you will have EntityC-entries in the database that now have NULL reference (to EntityB) - This is rarely what you want when C really is dependend on B... – Pieter

@MarioB we will all die anyway, so who cares – Egbert

Interesting attitude. I guess if you don't care about null entries it does not matter. Still it would be nice to make people aware of the drawbacks of this solution - this seems like dangerous advice for many use cases – Pieter

@MarioB Challenges make us stronger and we all decide individually how to deal best with life. In my opinion it is best to deal with it playfully and realize that we are actors on a stage. The show will end and new actors will enter the stage. So it helps to loosen up. That will also lead to better solutions with more creativity. That is my advice for the reader of this comment. – Egbert

Removing orphan helped me too, thank a lot – Kenwee

Answer 10

I used @user2709454 approach with small improvement.

public class User {
    private Set<Role> roles;

    public void setRoles(Set<Role> roles) {
        if (this.roles == null) {
            this.roles = roles;
        } else if(this.roles != roles) { // not the same instance, in other case we can get ConcurrentModificationException from hibernate AbstractPersistentCollection
            this.roles.clear();
            if(roles != null){
                this.roles.addAll(roles);
            }
        }
    }
}

Imitate

Answer 11

I had the same issue, but it was when the set was null. Only in the Set collection, in List work fine. You can try to the hibernate annotation @LazyCollection(LazyCollectionOption.FALSE) instead of JPA annotation fetch = FetchType.EAGER.

My solution: This is my configuration and work fine

@OneToMany(mappedBy = "format", cascade = CascadeType.ALL, orphanRemoval = true)
@LazyCollection(LazyCollectionOption.FALSE)
private Set<Barcode> barcodes;

@OneToMany(mappedBy = "format", cascade = CascadeType.ALL, orphanRemoval = true)
@LazyCollection(LazyCollectionOption.FALSE)
private List<FormatAdditional> additionals;

Gardant

Answer 12

HAS RELATION TYPE:

---

Don't try to instantiate the collection when it's declared in hasMany, just add and remove objects.

class Parent {
    static hasMany = [childs:Child]
}

---

USE RELATION TYPE:

---

But the collection could be null only when is declared as a property (use relation) and is not initialized in declaration.

class Parent {
    List<Child> childs = []
}

Pibgorn

Answer 13

The only time I get this error is when I try to pass NULL into the setter for the collection. To prevent this, my setters look like this:

public void setSubmittedForms(Set<SubmittedFormEntity> submittedForms) {
    if(submittedForms == null) {
        this.submittedForms.clear();
    }
    else {
        this.submittedForms = submittedForms;
    }
}

Colorfast

Answer 14

I had this problem when trying to use TreeSet. I did initialize oneToMany with TreeSet which works

@OneToMany(mappedBy = "question", fetch = FetchType.EAGER, cascade = { CascadeType.ALL }, orphanRemoval=true)
@OrderBy("id")
private Set<WizardAnswer> answers = new TreeSet<WizardAnswer>();

But, this will bring the error described at the question above. So it seems that hibernate supported SortedSet and if one just change the line above to

@OneToMany(mappedBy = "question", fetch = FetchType.EAGER, cascade = { CascadeType.ALL }, orphanRemoval=true)
@OrderBy("id")
private SortedSet<WizardAnswer> answers;

it works like magic :) more info on hibernate SortedSet can be here

Transfuse

Perhaps, it's better to user Collections.emptySet() to use a singleton empty list – Dish

Answer 15

There is this bug which looks suspiciously similar: https://hibernate.atlassian.net/browse/HHH-9940.

And the code to reproduce it: https://github.com/abenneke/sandbox/tree/master/hibernate-null-collection/src/test

There are 2 possible fixes to this:

• the collection is initialized with an empty collection (instead of null)

• orphanRemoval is set to false

Example - was:

@OneToMany(cascade = CascadeType.REMOVE,
        mappedBy = "jobEntity", orphanRemoval = true)
private List<JobExecutionEntity> jobExecutionEntities;

became:

@OneToMany(cascade = CascadeType.REMOVE,
        mappedBy = "jobEntity")
private List<JobExecutionEntity> jobExecutionEntities;

Demello

collection is initialized with an empty collection works for me – Nonpareil

Answer 16

One other cause may be using lombok.

@Builder - causes to save Collections.emptyList() even if you say .myCollection(new ArrayList());

@Singular - ignores the class level defaults and leaves field null even if the class field was declared as myCollection = new ArrayList()

My 2 cents, just spent 2 hours with the same :)

Chantellechanter

Answer 17

I was getting A collection with cascade=”all-delete-orphan” was no longer referenced by the owning entity instance when I was setting parent.setChildren(new ArrayList<>()). When I changed to parent.getChildren().clear(), it solved the problem.

Check for more details: HibernateException - A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance.

Ischia

Answer 18

@OneToMany(mappedBy = 'parent', cascade= CascadeType.ALL, orphanRemoval = true)
List<Child> children = new ArrayList<>();

I experienced the same error when I was adding child object to the existing list of Child Objects.

childService.saveOrUpdate(child);
parent.addToChildren(child);
parentService.saveOrUpdate(parent);

What resolved my problem is changing to:

child = childService.saveOrUpdate(child);

Now the child is revive with other details as well and it worked fine.

Kotick

Answer 19

As of 2021 and Spring Boot 2.5, it helped me to initialize the field right away when declaring it:

@OneToMany(mappedBy="target",fetch= FetchType.EAGER,cascade = CascadeType.ALL, orphanRemoval = true)
private List<TargetEntity> targets = new ArrayList<>();

Sharleensharlene

Funny, for me it was the opposite. There was an existing initialization, which I removed and then it worked. Using Quarkus 2.13.1 – Nuncio

Answer 20

Following solution worked for me

//Parent class
@OneToMany(mappedBy = 'parent', 
           cascade= CascadeType.ALL, orphanRemoval = true)
@OrderBy(value="ordinal ASC")
List<Child> children = new ArrayList<>()

//Updated setter of children 
public void setChildren(List<Children> children) {
    this.children.addAll(children);
    for (Children child: children)
        child.setParent(this);
}


//Child class
@ManyToOne
@JoinColumn(name="Parent_ID")
private Parent parent;

Hubblebubble

Answer 21

I am using Spring Boot and had this issue with a collection, in spite of not directly overwriting it, because I am declaring an extra field for the same collection with a custom serializer and deserializer in order to provide a more frontend-friendly representation of the data:

  public List<Attribute> getAttributes() {
    return attributes;
  }

  public void setAttributes(List<Attribute> attributes) {
    this.attributes = attributes;
  }

  @JsonSerialize(using = AttributeSerializer.class)
  public List<Attribute> getAttributesList() {
    return attributes;
  }

  @JsonDeserialize(using = AttributeDeserializer.class)
  public void setAttributesList(List<Attribute> attributes) {
    this.attributes = attributes;
  }

It seems that even though I am not overwriting the collection myself, the deserialization does it under the hood, triggering this issue all the same. The solution was to change the setter associated with the deserializer so that it would clear the list and add everything, rather than overwrite it:

  @JsonDeserialize(using = AttributeDeserializer.class)
  public void setAttributesList(List<Attribute> attributes) {
    this.attributes.clear();
    this.attributes.addAll(attributes);
  }

Biodynamics

Answer 22

Mine was completely different with Spring Boot! For me it was not due to setting collection property.

In my tests I was trying to create an entity and was getting this error for another collection that was unused!

After so much trying I just added a @Transactional on the test method and it solved it. Don't no the reason though.

Eisenach

The @Transactional annotation on test methods means that the database context will be rolled back at the end of the test method, regardless of its outcome. – Rakes

Answer 23

Had this issue with spring-boot 2.4.1 when running the tests in bulk from [Intellij Idea] version 2020.3. The issue doesn't appear when running only one test at a time from IntelliJ or when running the tests from command line.

Maybe Intellij caching problem?

Follow up:

The problem appears when running tests using the maven-surefire-plugin reuseForks true. Using reuseForks false would provide a quick fix, but the tests running time will increase dramatically. Because we are reusing forks, the database context might become dirty due to other tests that are run - without cleaning the database context afterwards. The obvious solution would be to clean the database context before running a test, but the best one should be to clean up the database context after each test (solving the root cause of the original problem). Using the @Transactional annotation on your test methods will guarantee that your database changes are rolled back at the end of the test methods. See the Spring documentation on transactions: https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#testcontext-tx.

Rakes

Answer 24

I face a similar issue where I was using these annotations in my parent entity :

@Cascade({ CascadeType.ALL, CascadeType.DELETE_ORPHAN })

Mistakenly, I was trying to save a null parent object in database and properly setting values to my entity object resolved my error. So, do check if you are silly setting wrong values or trying to save a null object in database.

Matchmark

Answer 25

I recently ran into this issue when refactoring some code. The original (and correct) code looked like this:

public virtual IEnumerable<SubscriptionPurchase> Purchases => _purchases;
public virtual SubscriptionPurchase MostRecentPurchase => _purchases.OrderByDescending(p => p.PurchaseDateUtc).FirstOrDefault();

I tried changing the code by moving the .OrderByDescending to the .Purchases property. This change broke the code and caused the referenced error in the OP:

public virtual IEnumerable<SubscriptionPurchase> Purchases => _purchases.OrderByDescending(p => p.PurchaseDateUtc);
public virtual SubscriptionPurchase MostRecentPurchase => Purchases.FirstOrDefault();

The error did not manifest until attempting to save the parent object that contained the .Purchases property.

As noted in other answers to this question, the problem occurs because the collection is being reset (in my case on every single access to .Purchases).

Midwifery

Answer 26

Adding my dumb answer. We're using Spring Data Rest. This was our pretty standard relationship. The pattern was used elsewhere.

//Parent class
@OneToMany(mappedBy = 'parent', 
           cascade= CascadeType.ALL, orphanRemoval = true)
@LazyCollection(LazyCollectionOption.FALSE)
List<Child> children = new LinkedList<>()


//Child class
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = 'ParentID', updatable = false)
@JsonBackReference
Parent parent

With the relationship we created, it was always intended that the children would be added through their own repo. I had not yet added the repo. The integration test we had was going through a complete lifecycle of the entity via REST calls so the transactions would close between requests. No repo for the child meant the json had the children as part of the main structure instead of in _embedded. Updates to the parent would then cause problems.

Iulus

Answer 27

Instead of assigning new collection

public void setChildren(Set<ChildEntity> children) {
    this.children = children;
}

Replace all elements with

public void setChildren(Set<ChildEntity> children) {
    Collections.replaceAll(this.children,children);
}

Mathieu

Answer 28

be careful with

BeanUtils.copyProperties(newInsum, insumOld,"code");

This method too break the hibernate.

Ferule

Answer 29

This is in contrast to the previous answers, I had exactly the same error: "A collection with cascade=”all-delete-orphan” was no longer referenced...." when my setter function looked like this:

public void setTaxCalculationRules(Set<TaxCalculationRule> taxCalculationRules_) {
    if( this.taxCalculationRules == null ) {
        this.taxCalculationRules = taxCalculationRules_;
    } else {
        this.taxCalculationRules.retainAll(taxCalculationRules_);
        this.taxCalculationRules.addAll(taxCalculationRules_);
    }
}

And then it disappeared when I changed it to the simple version:

public void setTaxCalculationRules(Set<TaxCalculationRule> taxCalculationRules_) {
    this.taxCalculationRules = taxCalculationRules_;
}

(hibernate versions - tried both 5.4.10 and 4.3.11. Spent several days trying all sorts of solutions before coming back to the simple assignment in the setter. Confused now as to why this so.)

Spectator

Answer 30

In my case it was concurrent access to one Hibernate Session from several threads. I had the Spring Boot Batch and RepositoryItemReader implementation where I fetched entities by page request with size 10.

For example my entities are:

@Entity
class JobEntity {
    @ManyToOne(fetch = FetchType.LAZY)
    private GroupEntity group;
}

@Entity
class GroupEntity {
    @OneToMany(mappedBy = "group", cascade = CascadeType.ALL, fetch = FetchType.LAZY, orphanRemoval = true)
    private Set<Config> configs; 
}

Batch process: reader -> processor -> writer in one transaction.

In that entities configuration, GroupEntity can escapes to other threads:

First thread that entered to read section fetches the page of JobEntity with size 10 (RepositoryItemReader#doRead), this items contain one shared GroupEntity object (because all of them pointed to the same group id). Then it takes the first entity. Next threads that come to read section take JobEntity from this page one by one, until this page will be exhausted.

So now threads have access to the same GroupEntity instance thought the JobEntity instances, that is unsafe multi thread access to the one Hibernate Session.

Misconstruction

Answer 31

Issue is solved when we make the child as final..

we should not change the reference of the child in constructor as well as setter.

Lippert

Answer 32

For me i had this association in my entity

@OneToMany(mappedBy = "course", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true)
private Set<Schedule> schedules = new HashSet<>();

And my update function

@̶T̶r̶a̶n̶s̶a̶c̶t̶i̶o̶n̶a̶l
public void updateCourseSchedule(Course course, Set<Schedule> schedules) {
    course.setSchedules(schedules);
    courseRepo.save(course);
}

When i remove the @Transactional annotation, it works

Grum

Answer 33

@OneToMany(mappedBy = "entity_b", cascade = [CascadeType.ALL] , orphanRemoval = true)

I was encountering the same error. It worked when I deleted the ;"orphanRemoval = true" part in the above structure

Doolittle

But what if I don't use orphanRemoval just for funsies but because it adds functionality I need? Just deleting randoms parts of your code is not how you solve problems... – Klaipeda