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 books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.