user manual

Chapter 14: Entity Beans and CMP 1.1 in Borland Enterprise Server 141
Container-Managed Persistence in Borland Enterprise Server
Now examine the code for both classes:
//Address Class
public class Address extends EntityBean {
public int id;
public String street1;
public String street1;
public String city;
public String state;
public String zip;
public Country country; // this is a direct pointer to the Country
}
//Country Class
public class Country extends EntityBean {
public int id;
public String name;
public int exchange;
public String currency;
}
In order for the Container to resolve the reference from the Address class to the
Country class, you must specify information about the Country class in the
deployment descriptor. Using the <ejb-link> entry in the deployment
descriptor, you instruct the Container to link the reference to the field
Address.country to the JNDI name for the home object, CountryHome. (Look at the
pigs example for a more detailed explanation.) The container optimizes this
cross-entity reference; because of the optimization, using the cross reference
is as fast as storing the value of the foreign key.
However, there are two important differences between using a cross reference
and storing the foreign key value:
When you use a cross reference pointer to another entity, you do not have
to call the other entity's home object findByPrimaryKey() method to retrieve
the corresponding object entity. Using the above example as an illustration,
the Address.country pointer to the Country object lets you retrieve the country
object directly. You do not have to call
CountryHome.findByPrimaryKey(address.country) to get the Country object that
corresponds to the country id.
When you use a cross reference pointer, the state of the referenced entity
is only loaded when you actually use it. It is not automatically loaded when
the entity containing the pointer is loaded. That is, merely loading in an
Address object does not actually load in a Country object. You can think of the
Address.country field as a "lazy" reference, though when the underlying
object is actually used does a "lazy" reference load in its corresponding
state. (Note that this "lazy" behavior is a part of the EJB model.) This facet
of the EJB model results in the decoupling of the life cycle of Address.country
from the life cycle of the Address bean instance itself. According to the
model, Address.country is a normal entity EJBObject reference; thus, the
state of Address.country is only loaded when and if it is used. The Container
follows the EJB model and controls the state of AddressBean.country as it
does with any other EJBObject.