web server - Borland Technical Publications

Container-Managed Persistence in Borland Enterprise Server
Container-Managed Persistence in Borland Enterprise Server
The Borland Enterprise Server's EJB Container is fully J2EE 1.3 compliant. The bean
provider designs persistence schemas for their entity beans, determined the methods
for accessing container-managed fields and relationships, and defines these in the
beans' deployment descriptor. The deployer maps this persistence schema to the
database and creates any other necessary classes for the beans' maintenance.
Information on J2EE 1.3 entity beans and CMP 2.0 is found in Chapter 16, “Using BES
Properties for CMP 2.x.”
BES CMP engine's CMP 1.1 implementation
While you don't have to be an expert on all aspects of the Borland CMP engine to use
it effectively, it is helpful to have some knowledge of certain areas. This section
provides information on the areas that users of the CMP engine should understand. In
particular, it focuses on the deployment descriptor file and the XML statements
contained within the file.
Before continuing, there are some key things to note in the implementation of an entity
bean that uses 1.1 container-managed persistence:
■
■
■
■
■
The entity bean has no implementations for finder methods. The EJB Container
provides the finder method implementations for entity beans with containermanaged
persistence. Rather than providing the implementation for finder methods
in the bean's class, the deployment descriptor contains information that enables the
container to implement these finder methods.
The entity bean declares all fields public that are managed by the container for the
bean. The CheckingAccount bean declares name and balance to be public fields.
The entity bean class implements the seven methods declared in the EntityBean
interface: ejbActivate(), ebjPassivate(), ejbLoad(), ejbStore(), ejbRemove(),
setEntityContext(), and unsetEntityContext(). However, the entity bean is required
to provide only skeletal implementations of these methods, though it is free to add
application-specific code where appropriate. The CheckingAccount bean saves the
context returned by setEntityContext() and releases the reference in
unsetEntityContext(). Otherwise, it adds no additional code to the EntityBean
interface methods.
There is an implementation of the ejbCreate() method (because this entity bean
allows callers of the bean to create new checking accounts), and the implementation
initializes the instance's two variables, account name and balance amount, to the
argument values. The ejbCreate() method returns a null value because, with
container-managed persistence, the container creates the appropriate reference to
return to the client.
The entity bean provides the minimal implementation for the ejbPostCreate()
method, though this method could have performed further initialization work if
needed. For beans with container-managed persistence, it is sufficient to provide
just the minimal implementation for this method because ejbPostCreate() serves as
a notification callback. Note that the same rule applies to the methods inherited from
the EntityBean interface as well.
Providing CMP metadata to the Container
According to the EJB Specification, the deployer must provide CMP metadata to the
EJB container. The Borland Container captures the CMP-relevant metadata in the XML
deployment descriptor. Specifically, the Borland Container uses the vendor-specific
portion of the deployment descriptor for the CMP metadata.
Chapter 14: Entity Beans and CMP 1.1 in Borland Enterprise Server 115