Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate EJB applications
Migrate enterprise bean code from v1.1 to v2.1
EJB v2.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 v1.x and v2.1 beans.
The EJB v2.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 v1.1 beans are reassembled into an EJB 2.1-compliant module, the EJB container synchronizes the state of v1.1 beans as well as that of v2.1 beans. As a result, you might notice some change in application behavior even though the application code for the v1.1 beans has not been changed.
The following information generally applies to any enterprise bean that currently complies with v1.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, 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.
EJB Query Language has the following limitations in Application Developer v5:
- 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 v1.1, the container performs the rollback only if the instance has called setRollbackOnly() on its EJBContext object.
- In EJB v1.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.
Task overview: Using enterprise beans in applications