web server - Borland Technical Publications

Container-Managed Persistence in Borland Enterprise Server
There are two classes that represent the entities which correspond to these tables, the
Address and Country classes. The Address class contains a direct pointer, country, to the
Country entity. This direct pointer reference is an EJBObject reference; it is not a direct
Java reference to the implementation bean.
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 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.
Container-managed field names
The Borland Container has changed the container-managed persistent field names so
that they are more Java friendly. SQL column names often prepend a shortened form
of the table name, followed by an underscore, to each column name. For example, in
the address table, there is a column for the city called addr_city. The full reference to
this column is address.addr_city. With the Borland Container, this maps to the Java
Chapter 14: Entity Beans and CMP 1.1 in Borland Enterprise Server 119