Hibernate hard facts – Part 6

In the sixth article of this serie, I will show you how to use the fetch profile feature introduced in Hibernate 3.5.

• Part 1: Updating a persistent object
• Part 2: Directional associations
• Part 3: Custom type mapping
• Part 4: Choosing between get() and load()
• Part 5: Manage logical DELETE

Lazy loading is a core feature in Hibernate: it saves memory space. The reasoning behind it is, if you don’t use an association, you don’t need the object and thus, Hibernate does not load it into memory. Hibernate fills the lazy loaded attribute with a proxy that makes the SQL request when the getter is called. By default, Hibernate makes all one-to-many and man-to-many associations lazy by default.

This is all well and good but  in some use-cases, the associations are needed. Two things may happen from here:

• either the session is still open and you make one more call to the database (and if done all the time, will cause performance problems),
• or the session is closed and you will get the infamous LazyInitializationException. This one is a favorite of many fresh Hibernate developers.

In order to mitigate these, Hibernate propose a fetch strategy that works not on the mapping level, but on the request level. Thus, you can still have lazy loading mappings but eager fetching in some cases. This strategy is available both in the Criteria API (criteria.setFetchMode()) and HQL ("FETCH JOIN").

Before Hibernate 3.5, however, you were stuck with setting the fetch mode of an association with each request. If you had a bunch of requests that needed an eager association, flagging the association as “join” each time was not only a waste of time but also a source of potential errors.

Hibernate 3.5 introduced the notion of fetch profiles: a fetch profile is a placeholder where you configure fetch mode for specific associations.

Each fetch profile has a name and an array of fetch overrrides. Fetch overrides do override the mapping association type. In the following example, all customer.getAccounts() class will be eager when activating the EAGER-ACCOUNTS profile.

@FetchProfile(
  name = "EAGER-ACCOUNTS",
  fetchOverrides = @FetchOverride(entity = Customer.class, association = "accounts", mode = FetchMode.JOIN))

Then, enabling the profile for a session is a no-brainer.

session.enableFetchProfile("EAGER-ACCOUNTS")

Granted, it’s not much, but you can gain much time with this feature. This example is very simple but you can have many fetch overrides under one profile (this may even be a good practice).

To go further:

• Fetch profiles on Hibernate documentation
• Fetch profiles on Hibernate Annotations documentation