public final Enum FetchMode

Use an outer join to load all instances of the related entity or collection at once, as part of the execution of a query. No subsequent queries are executed.

This is the default fetching strategy for an association or collection that is explicitly marked for eager fetching.

This fetching strategy is incompatible with lazy fetching since the associated data is retrieved as part of the initial query.

Use a secondary select to load a single associated entity or collection, at some point after an initial query is executed.

This is the default fetching strategy for any association or collection in Hibernate, unless the association or collection is explicitly marked for eager fetching.

This fetching strategy is vulnerable to the "N+1 selects" bugbear, though the impact may be alleviated somewhat via:

• enabling batch fetching using BatchSize, or
• ensuring that the associated entity or collection may be retrieved from the second-level cache.

This fetching strategy is, in principle, compatible with both eager and lazy fetching. On the other hand, performance considerations dictate that it should only be used in combination wih EAGER fetching when it is almost certain that the associated data will be available in the second-level cache.

Use a secondary select with a subselect that re-executes an initial query to load all instances of the related entity or collection at once, at some point after the initial query is executed. This fetching strategy is currently only available for collections and many-valued associations.

This advanced fetching strategy is compatible with both eager and lazy fetching.

Subselect fetching may be contrasted with batch fetching:

• In batch fetching, a list of primary key values is sent to the database, bound within a SQL in condition.
• In subselect fetching, the primary keys are determined by re-execution of the initial query within a SQL subselect.