Removing objects where ManyToMany relationships exist

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

@ManyToMany
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.

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 EntityNotFoundException, 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.