5.7. Eager Fetching

5.7.1. Configuring Eager Fetching
5.7.2. Eager Fetching Considerations and Limitations

Eager fetching is the ability to efficiently load subclass data and related objects along with the base instances being queried. Typically, Kodo has to make a trip to the database whenever a relation is loaded, or when you first access data that is mapped to a table other than the least-derived superclass table. If you perform a query that returns 100 Person objects, and then you have to retrieve the Address for each person, Kodo may make as many as 101 queries (the initial query, plus one for the address of each person returned). Or if some of the Person instances turn out to be Employees, where Employee has additional data in its own joined table, Kodo once again might need to make extra database trips to access the additional employee data. With eager fetching, Kodo can reduce these cases to a single query.

Eager fetching only affects relations in the active fetch groups, and is limited by the declared maximum fetch depth and field recursion depth (see Section 5.6, “Fetch Groups”). In other words, relations that would not normally be loaded immediately when retrieving an object or accessing a field are not affected by eager fetching. In our example above, the address of each person would only be eagerly fetched if the query were configured to include the address field or its fetch group, or if the address were in the default fetch group. This allows you to control exactly which fields are eagerly fetched in different situations. Similarly, queries that exclude subclasses aren't affected by eager subclass fetching, described below.

Eager fetching has three modes:

5.7.1. Configuring Eager Fetching

You can control Kodo's default eager fetch mode through the kodo.jdbc.EagerFetchMode and kodo.jdbc.SubclassFetchMode configuration properties. Set each of these properties to one of the mode names described in the previous section: none, join, parallel. If left unset, the eager fetch mode defaults to parallel and the subclass fetch mode defaults to join. These are generally the most robust and performant strategies.

You can easily override the default fetch modes at runtime for any lookup or query through Kodo's fetch configuration APIs. See Chapter 9, Runtime Extensions for details.

Example 5.20. Setting the Default Eager Fetch Mode

JPA XML format:

<property name="kodo.jdbc.EagerFetchMode" value="parallel"/>
<property name="kodo.jdbc.SubclassFetchMode" value="join"/>

JDO properties format:

kodo.jdbc.EagerFetchMode: parallel
kodo.jdbc.SubclassFetchMode: join

Example 5.21. Setting the Eager Fetch Mode at Runtime


import org.apache.openjpa.persistence.*;
import org.apache.openjpa.persistence.jdbc.*;


Query q = em.createQuery ("select p from Person p where p.address.state = 'TX'");
OpenJPAQuery oq = OpenJPAPersistence.cast (q);
JDBCFetchPlan fetch = (JDBCFetchPlan) oq.getFetchPlan ();
fetch.setEagerFetchMode (JDBCFetchPlan.EAGER_PARALLEL);
fetch.setSubclassFetchMode (JDBCFetchPlan.EAGER_JOIN);
List results = q.getResultList ();


import kodo.jdo.jdbc.*;


Query q = pm.newQuery (Person.class, "address.state == 'TX'");
JDBCFetchPlan fetch = (JDBCFetchPlan) q.getFetchPlan ();
fetch.setEagerFetchMode (JDBCFetchPlan.EAGER_PARALLEL);
fetch.setSubclassFetchMode (JDBCFetchPlan.EAGER_JOIN);
List results = (List) q.execute ();

You can specify a default subclass fetch mode for an individual class with the metadata extension described in Section, “Subclass Fetch Mode”. Note, however, that you cannot "upgrade" the runtime fetch mode with your class setting. If the runtime fetch mode is none, no eager subclass data fetching will take place, regardless of your metadata setting.

This applies to the eager fetch mode metadata extension as well (see Section, “Eager Fetch Mode”). You can use this extension to disable eager fetching on a field or to declare that a collection would rather use joins than parallel selects or vice versa. But an extension value of join won't cause any eager joining if the fetch configuration's setting is none.

5.7.2. Eager Fetching Considerations and Limitations

There are several important points that you should consider when using eager fetching:

  • When you are using parallel eager fetch mode and you have large result sets enabled (see Section 4.11, “Large Result Sets”) or you place a range on a query, Kodo performs the needed parallel selects on one page of results at a time. For example, suppose your FetchBatchSize is set to 20, and you perform a large result set query on a class that has collection fields in the configured fetch groups. Kodo will immediately cache the first 20 results of the query using join mode eager fetching only. Then, it will issue the extra selects needed to eager fetch your collection fields according to parallel mode. Each select will use a SQL IN clause (or multiple OR clauses if your class has a compound primary key) to limit the selected collection elements to those owned by the 20 cached results.

    Once you iterate past the first 20 results, Kodo will cache the next 20 and again issue any needed extra selects for collection fields, and so on. This pattern ensures that you get the benefits of eager fetching without bringing more data into memory than anticipated.

  • Once Kodo eager-joins into a class, it cannot issue any further eager to-many joins or parallel selects from that class in the same query. To-one joins, however, can recurse to any level.

  • Using a to-many join makes it impossible to determine the number of instances the result set contains without traversing the entire set. This is because each result object might be represented by multiple rows. Thus, queries with a range specification or queries configured for lazy result set traversal automatically turn off eager to-many joining.

  • Kodo cannot eagerly join to polymorphic relations to non-leaf classes in a table-per-class inheritance hierarchy. You can work around this restriction using the mapping extensions described in Section, “Nonpolymorphic”.


Skip navigation bar   Back to Top