When Entity Beans Are Not an Option

A couple of EJB 1.0 servers do not support entity beans. This is a legitimate choice, since support for entity beans is not required in EJB 1.0.[44] This section provides some strategies for developing systems that only use session beans for EJB 1.0 developers.

Entity bean support is required in EJB 1.1. If you’re using EJB 1.1, you can skip this section.

Emulating Entity Beans with Session Beans

Session beans that implement the SessionSynchronization interface (discussed in Chapter 8) can emulate some of the functionality of bean-managed entity beans. This approach provides a couple of advantages. First, these session beans can represent entity business concepts like entity beans; second, dependency on vendor-specific object-to-relational mapping tools is avoided.

Unfortunately, session beans were never designed to represent data directly in the database, so using them as a replacement for entity beans is problematic. Entity beans fulfill this duty nicely because they are transactional objects. When the attributes of a bean are changed, the changes are reflected in the database automatically in a transactionally safe manner. This cannot be duplicated in stateful session beans because they are transactionally aware but are not transactional objects. The difference is subtle but important. Stateful session beans are not shared like entity beans. There is no concurrency control when two clients attempt to access the same bean at the same time. ...

Get Enterprise JavaBeans, Second Edition now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.