Entity Beans naturally are "lazy loaders". A CMR field holds a reference to a local component interface or a collection of local interfaces. The (related) entity itself is only loaded by the container once you invoke a business method through that local interface.
I anything, a vendor extension (not the spec) may allow you to specify eager-loads of entities that you will most likely need - as long as you can guarantee that the EJB Server is total control of that portion of the underlying persistent store - so that it doesn't waste time on unnecessary ejbLoads().
Indeed, most application servers allow you to influence the loading strategy for entity beans that participate in relationships (via their local business interfaces). You can have lazy-loading (my guess this is a natural default, since it usually provides optimal performance when dealing with multiple relationships), and eager-loading . With eager-loading, use it as "full" (i.e. when a bean gets loaded, load all beans that participate in a relationship with the first bean, even indirectly) with caution, since it can easily generate a whole bunch of ejbLoad() calls and unnecessary bean instances (especially when we�re dealing with many-to-many or many-to-one relationships). Of course, the lazy-loading tradeoff is more computation during bean access. It is up to you to dig in the AS documentation and see what can and what can not be done and decide your strategy. Just remember that loading strategies and a number of other optimizations are beyond (i.e. not specified) in the ejb specification. That leaves room for the AS vendors to optimize and make us AS users happier (at least in theory)
SCJP for Java 1.4<br />SCBCD for J2EE 1.3
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop