Java Reference
In-Depth Information
The bean is shared (that is, accessed simultaneously) by multiple clients.
Primary keys
Similar to a row stored in a database table, each entity bean has a unique object identifier called a
primary key
. A customer entity bean, for example, might be identified by a customer number. Note that
the primary key of an entity bean is an object. In most cases, it may be simply a
String
object,
although it can be more complex. If the number (or integer) is used in the underlying database table, the
Java wrapper classes (such as
java.lang.Integer
or
java.lang.Long
) need to be used for the
primary key class. The primary key object enables the client to locate a particular entity-bean instance.
Persistent Storage
When an entity bean is created, the data that the EJB represents is placed into the persistent storage,
typically through a database insert operation, and a copy of that data is stored in the memory as part of
the EJB instance. Whenever the attributes of the in-memory EJB instance are modified, their underlying
persistent counterparts are automatically updated by the EJB container.
Since an entity bean's value is stored in a persistent manner, multiple clients can access the same data
at the same time. In others words, entity beans allow shared access just as a relational database allows
multiple users to access its data simultaneously. EJB containers can implement two or more clients
requesting accesses to the same data in a variety of ways. Because these clients might want to change
the same data, it's important that entity beans work within transactions. Typically, the EJB container
provides transaction management. In this case, bean developers or application assemblers specify the
transaction attributes in the bean's deployment descriptor. A bean developer does not have to code the
transaction boundaries in the bean — the container marks the boundaries based on the transaction
attributes specified in the deployment descriptor. Transaction attributes are discussed later in this
chapter.
Because the state of an entity bean is saved in a persistent storage, it exists beyond the lifetime of the
application or the server process. For example, data stored in a database still exists even after you shut
down the database server or the applications it serves.
Bean-managed persistence
There are two types of persistence for entity beans: bean managed and container managed. With bean-
managed persistence (BMP), the EJB itself is responsible for writing all of the logic necessary for
synchronizing the data between itself and the persistent store. The entity bean code that a bean
developer writes contains all the calls that access the database. A BMP bean must manage the four
following operations:
Add an entry to the persistent store.
Remove an entry from persistent store.
Update the persistent store with the current attribute values of the entity bean instance.
Update the attributes of bean instance with values stored in persistent store.
Effectively, a bean developer is responsible for coding all of the database queries. However, the
container still controls the life cycle of the bean itself.
Cross-
Reference
BMP entity beans are discussed in more detail in
Chapter 21
.
Container-managed persistence
Container-managed persistence (CMP) means that the EJB container handles all database access
required by the entity bean. The bean's code contains no database access (SQL) calls. As a result, the
bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility,
even if you redeploy the same entity bean on different J2EE-compliant application servers that use
different databases, you will not need to modify or recompile the bean's code. In short, CMP entity
beans are more portable. To generate the data-access calls, the container needs information that a
bean developer provides in the entity bean's deployment descriptor.
