Spring/Hibernate: Bidirectional Mapping without synchronization for JPQL queries only

Question

In a bidirectional mapping between entities (e.g. @ManyToOne ↔ @OneToMany), the counterpart needs to be synchronized on every change, especially when using a 2^nd level cache. This is usually done with helper methods. Those helper methods do not perform well if the Many part contains a lot of entries, because the whole set is fetched each time. A simple example would be an entity Store which has n Products, whereas n is very large. Adding a new Product to the Store would require the Store to fetch the whole list of Products to finally add it to the set (see code example below).

One could argue, that when modelling such a relation it would be better represented with an unidirectional association from the Product to the Store. We are using many JPQL queries in our application though. In JPQL, it comes very handy to join entities from both sides.

Do you see any problems when mapping the @OneToMany relation in the Store entity, when Many actually means many and not just a few, and just make the field private, without getters and setters, provided that the whole relation is lazily fetched? As I understand, Hibernate just needs the field to map the relation. And if the set is private, no performance issues should occur?

---

The Product entity:

@Entity
@Table(name = "product")
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Product {

  @ManyToOne(fetch = FetchType.LAZY)
  private Store store;

  // setter, getter, helper methods
}

The Store entity:

@Entity
@Table(name = "store")
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Store {

  @OneToMany(mappedBy = "products", fetch = FetchType.LAZY)
  @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
  private Set<Product> products;

  // setter, getter, helper methods
}

Answer 1

No, there is nothing wrong with it, it's a technique I've used often as well. Of course just make sure that the field is not accessed reflectively in some context (like automatic toString builders and similar utilities you may be using).

Also, you don't need the @Cache annotation on it since you will never access the collection anyway, thus it will never be cached.