Hibernate3 loads a single entity instance if you retrieve it by identifier through get() or load(). All collections mapped for this entity, and all associated entities, be it through -to-many or -to-one associations, are not loaded. For collections there are "wrappers" in place, for single-ended associations, "proxies" are used by default.
If you then navigate from the loaded entity instances to a collection (and iterate through it), or to a single associated second entity, an additional SELECT will be executed to fetch exactly what you just hit in your code. This effectively produces n+1 selects.
Two different and complementary ways to change this behavior:
1. Go into your mapping and change the _global_ behavior of a particular collection or association. We have two notions: What should be fetched and how should it be fetched:
- You can switch to an _immediate_ non-lazy second SELECT by setting lazy="false" on a collection. You can switch to an _immediate_ non-lazy second SELECT for single-ended associations by disabling proxies on the target entity (<class name=B lazy=false>).
- With a batch-size on a collection or on a class mapping you tell Hibernate to optimize the second SELECT by fetching up to n other collections (or entity instances) when you hit one in Java, depending on how many you expect to be in the Session already. This is a blind-guess optimization technique, but very nice for nested tree node loading.
- With fetch="subselect" on a collection you can tell Hibernate to not only load this collection in the second SELECT (lazy or non-lazy), but also all other collections for all other entities of the same type you loaded in the first SELECT. This is especially useful for "serial" collection fetching.
- Setting a collection or -to-one association to fetch="join" will actually avoid the second SELECT, but use just one "bigger" outer-join SELECT to get both the owning and the referenced entity instance (or collection). If you fetch="join" more than one collection for a particular entity instance (both in "parallel"), you create a Cartesian product and two SELECTs would probably be faster.
2. You can override or completely redefine the "what is loaded" and "how is it loaded" using APIs programmatically, at runtime:
- Criteria respects the laziness settings in your mappings and guarantees that what you want loaded, is loaded. This means one Criteria query might result in several SQL immediate SELECTs to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how", use setFetchMode() for a particular property.
- HQL respects the laziness settings in your mappings and guarantees that what you want loaded, is loaded. This means one HQL query might result in several SQL immediate SELECTs to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how", use "left join fetch" for outer-join fetching of particular collections or -to-one associated entities.
Finally, there are more advanced settings:
- lazy="true" on -to-one associations and <property> mappings, used with bytecode instrumentation as an alternative to proxies and for lazy loading of individual scalar properties (both somewhat exotic)
- lazy="extra" on collections for "smart" collection behavior, i.e. some collection operations such as size(), contains(), etc. do not trigger an initialization of the collection, but execute additional SQL
- some more exotic optimizations you will find out when you know more about Hibernate, but the above is 95%
Now, if you want to do something good, put this on the Wiki as "A short primer on fetch strategies". Thanks
Login
FAQ
Search
