Eager loading of associations and collections in Java

Generating QR in Java Eager loading of associations and collections

You ve seen that Hibernate is lazy by default. All associated entities and collections aren t initialized if you load an entity object. Naturally, you often want the opposite: to specify that a particular entity association or collection should always be loaded. You want the guarantee that this data is available in memory without an additional database hit. More important, you want a guarantee that, for example, you can access the seller of an Item if the Item instance is in detached state. You

have to define this fetch plan, the part of your object network that you want to always load into memory. Let s assume that you always require the seller of an Item. In Hibernate XML mapping metadata you d map the association from Item to User as lazy="false":

<class name="Item" table="ITEM"> ... <many-to-one name="seller" class="User" column="SELLER_ID" update="false" not-null="true" lazy="false"/> ... </class>

The same always load guarantee can be applied to collections for example, all bids of an Item:

<class name="Item" table="ITEM"> ... <many-to-one name="seller" lazy="false" .../> <set name="bids" lazy="false" inverse="true"> <key column="ITEM_ID"/> <one-to-many class="Bid"/> </set> ... </class>

If you now get() an Item (or force the initialization of a proxied Item), both the seller object and all the bids are loaded as persistent instances into your persistence context:

Item item = (Item) session.get(Item.class, new Long(123));

The persistence context after this call is shown graphically in figure 13.3. Other lazy mapped associations and collections (the bidder of each Bid instance, for example) are again uninitialized and are loaded as soon as you access them. Imagine that you close the persistence context after loading an Item. You can now navigate, in detached state, to the seller of the Item and iterate through all the bids for that Item. If you navigate to the categories this Item is assigned to, you get a LazyInitializationException! Obviously, this collection

wasn t part of your fetch plan and wasn t initialized before the persistence context was closed. This also happens if you try to access a proxy for example, the User that approved the item. (Note that you can access this proxy two ways: through the approvedBy and bidder references.) With annotations, you switch the FetchType of an entity association or a collection to get the same result:

@Entity public class Item { ... @ManyToOne(fetch = FetchType.EAGER) private User seller; @OneToMany(fetch = FetchType.EAGER) private Set<Bid> bids = new HashSet<Bid>(); ... }

The FetchType.EAGER provides the same guarantees as lazy="false" in Hibernate: the associated entity instance must be fetched eagerly, not lazily. We already mentioned that Java Persistence has a different default fetch plan than Hibernate. Although all associations in Hibernate are completely lazy, all @ManyToOne and

@OneToOne associations default to FetchType.EAGER! This default was standard-

ized to allow Java Persistence provider implementations without lazy loading (in practice, such a persistence provider wouldn t be very useful). We recommend that you default to the Hibernate lazy loading fetch plan by setting FetchType. LAZY in your to-one association mappings and only override it when necessary:

@Entity public class Item { ... @ManyToOne(fetch = FetchType.LAZY) private User seller; ... }

You now know how to create a fetch plan; that is, how you define what part of the persistent object network should be retrieved into memory. Before we show you how to define how these objects should be loaded and how you can optimize the SQL that will be executed, we d like to demonstrate an alternative lazy loading strategy that doesn t rely on proxies.

Runtime proxy generation as provided by Hibernate is an excellent choice for transparent lazy loading. The only requirement that this implementation exposes is a package or public visible no-argument constructor in classes that must be proxied and nonfinal methods and class declarations. At runtime, Hibernate generates a subclass that acts as the proxy class; this isn t possible with a private constructor or a final entity class. On the other hand, many other persistence tools don t use runtime proxies: They use interception. We don t know of many good reasons why you d use interception instead of runtime proxy generation in Hibernate. The nonprivate constructor requirement certainly isn t a big deal. However, in two cases, you may not want to work with proxies:

The only cases where runtime proxies aren t completely transparent are polymorphic associations that are tested with instanceof. Or, you may want to typecast an object but can t, because the proxy is an instance of a runtime-generated subclass. We show how to avoid this issue and how to work around the problem in chapter 7, section 7.3.1, Polymorphic many-to-one associations. Interception instead of proxies also makes these issues disappear.