Selecting a fetch strategy This seems to be an optimization you shouldn t make. Can you really say that whenever an item is needed, all its bids are needed as well ? Fetching strategies in mapping metadata work on a global level. We don t consider fetch=”join” a common optimization for collection mappings; you rarely need a fully initialized collection all the time. In addition to resulting in higher memory consumption, every OUTER JOINed collection is a step toward a more serious Cartesian product problem, which we ll explore in more detail soon. In practice, you ll most likely enable a batch or subselect strategy in your mapping metadata for the bids collection. If a particular procedure, such as this, requires all the bids for each Item in-memory, you modify the initial HQL or Criteria query and apply a dynamic fetching strategy: List- allItems = session.createQuery(”from Item i left join fetch i.bids”) .list(); List
- allItems = session.createCriteria(Item.class) .setFetchMode(”bids”, FetchMode.JOIN) .list(); // Iterate through the collections… Both queries result in a single SELECT that retrieves the bids for all Item instances with an OUTER JOIN (as it would if you have mapped the collection with join=”fetch”). This is likely the first time you ve seen how to define a fetching strategy that isn t global. The global fetch plan and fetching strategy settings you put in your mapping metadata are just that: global defaults that always apply. Any optimization process also needs more fine-grained rules, fetching strategies and fetch plans that are applicable for only a particular procedure or use case. We ll have much more to say about fetching with HQL and Criteria in the next chapter. All you need to know now is that these options exist. The n+1 selects problem appears in more situations than just when you work with lazy collections. Uninitialized proxies expose the same behavior: You may need many SELECTs to initialize all the objects you re working with in a particular procedure. The optimization guidelines we ve shown are the same, but there is one exception: The fetch=”join”setting on or associations is a common optimization, as is a @ManyToOne(fetch = FetchType.EAGER)
From our experience, we are can tell you that you can find a reliable and cheap webhost service at Java Web Hosting services.
This entry was posted
on Friday, February 8th, 2008 at 12:12 pm and is filed under j2ee.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.