Migrate enterprise bean code from Version 1.1 to Version 2.0

Enterprise JavaBeans (EJB) Version 2.0-compliant beans may be assembled only in an EJB 2.0-compliant module, although an EJB 2.0-compliant module can contain a mixture of Version 1.x and Version 2.0 beans.

The EJB Version 2.0 specification mandates that prior to the EJB container's executing a findByMethod query, the state of all enterprise beans enlisted in the current transaction be synchronized with the persistent store. (This is so the query is performed against current data.) If Version 1.1 beans are reassembled into an EJB 2.0-compliant module, the EJB container synchronizes the state of Version 1.1 beans as well as that of Version 2.0 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.

This 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 IBM WebSphere Studio Application Developer tool, see the documentation for that product.

1. In each container-managed persistence (CMP) bean, replace each CMP field with abstract get and set methods. In doing so, make each bean class abstract.
2. In each CMP bean, change all occurrences of this.field = value to setField(value).
3. In each CMP bean, create abstract get and set methods for the primary key.
4. In each CMP bean, create an EJB Query Language statement for each finder method.
5. In each CMP bean, change finder methods to return java.util.Collection instead of java.util.Enumeration.
6. 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.0, all non-application exceptions thrown by the bean instance result in the rollback of the transaction in which the instance is running, and 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.

7. Update rollback behavior as the result of application exceptions.
   • In EJB versions 1.1 and 2.0, 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.