The application server will store the conversational state somewhere and initialize the bean for
another client. When this client needs to make another method call the application server will
activate an instance of the bean for it to use. When a bean is passivated, the conversational
state is stored so that it is not lost. When an instance of the bean is activated again for use by
this client, the conversational state is restored to the same condition it was in at passivation.
Subsequent method calls are not necessarily handled by the same instance of the bean, how-
ever it does not matter because whenever a new instance is given to the client the conversa-
tional state is restored.
Activation and passivation are where the callback methods in the bean class come into play.
The ejbActivate() and ejbPassivate() methods are called during this process in case some
special processing is required to release or restore the state of the bean object.
Persistence is the primary difference between a session bean and an entity bean. The entity
bean represents some persistence, and this determines many of the processes involved in writ-
ing, deploying, and even using an entity bean.
When a client is accessing an entity bean, any changes that are made are automatically
reflected in the database. There is no need to tell the entity bean to store itself, or to hand it to
a database manager to be updated. This is all part of the contract between the container and all
entity beans. It is a great concept and we will take a brief look at how it is taken care of.
Entity beans are not totally different from session beans. They are all still Enterprise JavaBeans
and follow many of the same principles. There is still the concept of a home interface, which
controls lifecycle events; a remote interface, which provides access to business logic; and a
bean class, which handles all of the requests. For this reason, we will not repeat all of the con-
cepts discussed earlier on session beans. We will point out how they differ and address the con-
cepts specific to entity beans.
Who Handles the Persistence?
The Enterprise JavaBeans Specification enables the developer to write all of the code to handle
persistence, or enables the container to take care of everything. These two concepts are called
bean-managed persistence and container-managed persistence, respectively.
It is possible to write an entity bean and never write any database-related code. This is usually
the case when implementing beans using container-managed persistence. This sounds great,
but there are also disadvantages to this scheme also. You have less control over how the data is
stored, and possibly over the efficiency of the database transaction.