Home » Support » Forum » Removing objects where ManyToMany relationships exist

Removing objects where ManyToMany relationships exist


Consider you have an entity Entity with the following unidirectional relationship:

private Set<OtherEntity> setOfOtherEntities;

public Set<OtherEntity> getOtherEntities() {

    if (setOfOtherEntities == null) {
      setOfOtherEntities = new TreeSet<OtherEntity>();
    return setOfOtherEntities;

Now consider a number of OtherEntities are removed from the database. What happens with the numerous TreeSets for all the existing Entities in the database? Are OtherEntities that are referenced in a TreeSet automatically removed as well, so, the TreeSet is reduced in size? Or do I end up having a number of null pointers in the Sets? 

Would I need to manually go through all Entities in the database to check if there's a TreeSet where an entry points to an to-be-removed OtherEntity, to remove it from the Set manually? Hope not...

Thanks for your help!

Best regards, Benjamin


It is application responsibility to prevent broken references. When an OtherEntity object is deleted the application must also remove any references to it, including from the setOfOtherEntities TreeSet.

Broken references are not null values and they are more difficult to handle because accessing them cause exceptions. They are replaced with null values when the database is fixed using the Doctor.

In this specific scenario you may consider using a bidirectional relationship with OtherEntity as the owner because the non owner side (the mapped by side) is updated automatically.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Thank you for your answer and help. Two short follow-up questions:

  1. You write that trying to access a removed object via a broken reference throws exceptions. Is it always the same kind of exception, or could it potentially lead to a number of different exceptions, depending on state, query type, etc.?
  2. Your proposal to go with a bidirectional relationship: Do you consider this approach to scale well enough, even if there's millions of Entity and OtherEntity objects in the database, and ten-thousands of them have a relationship with each other?
  1. It should usually be EntityNotFoundExceptionjavax.persistence.EntityNotFoundExceptionJPA exceptionThrown by the persistence provider when an entity reference obtained by EntityManager.getReference is accessed but the entity does not exist.See JavaDoc Reference Page..., but sometimes it could be wrapped by another exception, and there may be cases in which another exception is thrown (e.g. in query execution). Anyway, you should not have broken references in the database intentionally.
  2. It depends. On retrieval - inverse (mapped by) collections are usually slower. On update - they may be slightly faster, mainly if they are very big. Notice, that with ORM (e.g. Hibernate, EclipseLink) collections are always implemented this way, i.e. a query is required in order to retrieve the content of a collection.
ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply

To post a reply and/or subscribe to update notifications - please login