One problem exists though: because it is so easy to set up @OneToMany associations and it makes traversing the object graph easier, you are likely to end up with @OneToMany associations where you don’t want them later on. In fact, what might be small set of data when you start a project, might end up becoming a large set when actual data flows through the program. So the safest thing of all would be to avoid @OneToMany associations altogether. Hmm…

After all of this time, I have finally come to the simple conclusion that using one-to-many relationships for large collections is a just a bad idea. Even if you are to get around the issues with lazy-loading, you still face the problem of the memory usage for the collection. We use EclipseLink’s “SoftWeak” caching strategy in general. But when one object holds a collection to hundreds or thousands of other entities that otherwise have only a weak reference, garbage collection is severely hampered. I basically draw the line at around 100 objects. Any relationship that would involve more than 100 objects is not a candidate for a collection mapping. This is not a hard and fast rule, but I have found that the cost of the extra DAO and service layer coding outweighs the hassles of dealing with these performance issues.

In that case one way to do it is to define the child as a separate entity with a composite primary key defined with the @IdClass annotation.

Is that what you are looking for? If not, please post the definition of your schema.

As I am new to jpa, please forgive the simplicity of the question. I have the following problem:

How can I read a collection of strings from a child table that references the parent table by a FK ? The database is legacy and I can not change it. This seems likes such a basic operation and it frustrates me that I do not know how to do it in JPA.

Thank You,
MPK

One remark about the last paragraph where you mention that the queued operations need to be propagated to the underlying set before the transaction is committed: this is not necessary when the set is not the owning side of a bidirectional relation (i.e.. when the set has the mappedBy field set on the @OneToMany annotation). And in most cases that is so.

In any case, you’d rather not do this last-minute propagation because initializating the set is expensive (the reason we are bothering with this pattern anyway).

But there are some gotchas, like ensuring any decorating collections are created only after the field injection of the ORM-managed fields has taken place. I guess @PostConstruct could be used for that, but that’s a bit ugly. Or you could use double checked locking.

So something like

class Entity {
  Collection persistedCollection;
  transient Collection lateLoadingPersistedCollection;

  @PostConstruct
  void createLateLoadingCollections() {
    lateLoadingPersistedCollection = new LateLoadingCollection(persistedCollection);
  }

  Collection getPersistedCollection() {
    return lateLoadingPersistedCollection;
  }

}

or

class Entity {
  Collection persistedCollection;

  // let's pretend closures made it to Java 7
  transient LazyField lateLoadingPersistedCollection =
    new LazyField({ new LateLoadingCollection(persistedCollection) });

  Collection getPersistedCollection() {
    assert persistedCollection != null;
    return lateLoadingPersistedCollection.get();
  }

}

where LazyField is just some wrapper around some double-checked locking lazy instantiation code.

Because both examples rely on returning the decorated collection from the getter, this presumably wouldn’t work with property access, by the way (but I guess that wouldn’t bother you).

The LateLoadingCollection itself would just be a decorator around the real, ORM-managed collection that would intercept the add and remove methods (storing the values in a queue or whatever) and would simply merge and then delegate to the underlying set in all other cases, which would result in a load whenever e.g. the iterator was called.

A key question here would be whether there is some guarantee that get (or any of the other methods that would result in a merge of any queued changes) would be called when an entity is persisted. Otherwise, changes to the underlying persistedCollection might not be saved, of course…