Enterprise JavaBeans (EJB) Version 2.1-compliant beans can be assembled
only in an EJB 2.1-compliant module, although an EJB 2.1-compliant module
can contain a mixture of Version 1.x and Version 2.1 beans.
About this task
The EJB Version 2.1 specification mandates that prior to the EJB
container starting a findByMethod query, the state of all enterprise
beans that are enlisted in the current transaction be synchronized with the
persistent store. (This action is so the query is performed against current
data.) If Version 1.1 beans are reassembled into an EJB 2.1-compliant module,
the EJB container synchronizes the state of Version 1.1 beans as well as that
of Version 2.1 beans. As a result, you might notice some change in application
behavior even though the application code for the Version 1.1 beans has not
been changed.
The following information generally applies to any enterprise
bean that currently complies with Version 1.1 of the EJB specification. For
more information about migrating code for beans produced with the Rational
Application Developer tool, see the documentation for that product.
Procedure
- In beans with container-managed persistence (CMP) version 1.x,
replace each CMP field with abstract get and set methods.
In
doing so, you must make each bean class abstract.
- In beans with CMP version 1.x, change all occurrences of this.field = value to setField(value).
- In each CMP bean, create abstract get and set methods for the primary
key.
- In beans with CMP version 1.x, create an EJB Query Language statement
for each finder method.
Note: EJB Query Language has the following
limitations in Application Developer Version 5:
- EJB Query Language queries involving beans with keys made up of relationships
to other beans appear as invalid and cause errors at deployment time.
- The IBM EJB Query Language support extends the EJB 2.1 specification in
various ways, including relaxing some restrictions, adding support for more
DB2 functions, and so on. If portability across various vendor databases or
EJB deployment tools is a concern, then care should be taken to write all
EJB Query Language queries strictly according to instructions described in
Chapter 11 of the EJB 2.1 specification.
- In finder methods for beans with CMP version 1.x, return java.util.Collection
instead of java.util.Enumeration.
- Update handling of non-application exceptions.
- To report non-application exceptions, throw javax.ejb.EJBException instead
of java.rmi.RemoteException.
- Modify rollback behavior as needed: In EJB versions 1.1 and 2.1, all non-application
exceptions thrown by the bean instance result in the rollback of the transaction
in which the instance is running; the instance is discarded. In EJB 1.0, the
container does not roll back the transaction or discard the instance if it
throws java.rmi.RemoteException.
- Update rollback behavior as the result of application exceptions.
- In EJB versions 1.1 and 2.1, an application exception does not cause the
EJB container to automatically roll back a transaction.
- In EJB Version 1.1, the container performs the rollback only if the instance
has called setRollbackOnly() on its EJBContext object.
- In EJB Version 1.0, the container is required to roll back a transaction
when an application exception is passed through a transaction boundary started
by the container.
- Update any CMP setting of application-specific default values
to be inside ejbCreate (not using global variables, since EJB 1.1 containers
set all fields to generic default values before calling ejbCreate, which overwrites
any previous application-specific defaults).
This approach also
works for EJB 1.0 CMPs.