Entity Bean Concepts

An entity bean is responsible for performing the data logic operations in an n-tier enterprise application. Because entity beans are objects that represent data in the database, each instance of an entity bean represents a specific row in the database. Therefore, the relationship between a database row and an entity bean instance is always one to one. Just as you can insert, update, and delete data in the database, you can also perform the same operations on an entity bean from client applications.

Entity beans allow shared access to multiple users, which means that if two client applications try to search for the same data in a database, they get to handle the same entity bean instance. An entity bean lives as long as the data exists in the database. The main difference between an entity bean and a session bean is that an entity bean can survive an EJB container crash. If a crash occurs, the entity bean's state will be automatically reset to the state of the last committed transaction, while the state of a session bean will be lost. The crash will not be fully transparent to the client though the client may receive an exception if it calls an entity in a container that has crashed. Last, but not the least, an entity bean, like any other EJB, is transaction-aware that is, it can take part in transactions spanning different application components. You will be studying how EJBs participate in transactions on Day 14, "Understanding JTA Transactions."

Figure 12.3 depicts the mapping between an entity bean and a database table. An entity bean shares certain characteristics with a session bean. Like a session bean, an entity bean has a life cycle, callback methods, and is made up of different components, such as a remote and home interface, and a bean implementation class. In addition to these components, an entity bean uses a primary key class to represent the unique attributes of data encapsulated by the entity bean.

Figure 12.3. Diagram showing an entity bean and how it maps to a database table.

Until this point you have learned that an entity bean persists data in a database and represents a row of data in the database. So, how does an entity bean interact with the database?

An entity bean uses a JDBC driver to interact with a database. Because entity beans are deployed in EJB containers, the common practice is to define a JDBC driver connection pool that can be used by all application components deployed on the EJB container or the application server. Using such a database connection, an entity bean can interact with the database in two ways:

• Bean managed persistence (BMP) The bean provider implements the functionality to interact with the database using JDBC statements. You will study BMP in more detail tomorrow.

• Container managed persistence (CMP) If the EJB container is delegated the responsibility of persistence, it performs the data retrieval and storage for the entity bean. One of the ways an EJB container maintains persistence is by using the newly introduced EJB Query Language. Today you will focus on CMP.

Entity beans were a part of the EJB 1.1 specification but were not frequently used because of their poor performance. The primary reason for this was the overhead required when using entity beans deployed in the same JVM of the EJB container via remote interfaces. The EJB 2.0 specification addresses this problem by introducing the concept of local interfaces. A local interface treats entity beans deployed in the same JVM of the EJB container as local classes. The caveat when using a local interface for an entity bean is that the entity bean can only be accessed by client applications or other EJBs deployed within the same JVM of the EJB container.