Java Reference
In-Depth Information
The container invokes the
ejbLoad
and
ejbStore
methods, plus the business methods between the
ejbLoad
and
ejbStore
methods, in the same transaction context. When, from these methods, the
EJB instance accesses the entity object's state in the database, the database properly associates all the
multiple database accesses with the transaction.
Because the EJB container needs a transaction context to drive the
ejbLoad
and
ejbStore
methods
on an EJB instance, caching of the entity object's state in the instance variables works reliably only if
the entity-bean methods execute in a transaction context.
The
ejbLoad
and
ejbStore
methods must be used with great caution for entity beans that do not
execute with a defined transaction context. These are entity beans with methods that use transaction
attributes
NotSupported
,
Never
, and
Supports
(the transaction attribute in
Chapter 20
). If the
business methods can execute without a defined transaction context, the instance should cache only
the state of the immutable entity objects. Fore these entity beans, an instance can use the
ejbLoad
method to cache the entity object's state but should never call the
ejbStore
method.
Cross-
Reference
See the section "
Container-Managed Transaction
" in
Chapter 20
for
discussions of the transaction attributes.
If the
ejbLoad
and
ejbStore
methods cannot locate an entity in the underlying database, they should
throw the
javax.ejb.NoSuchEntityException
. This exception is a subclass of
java.ejb.EJBException
. Because
EJBException
is a subclass of
RuntimeException
, you do
not have to include it in the
throws
clause. When
NoSuchEntityException
is thrown, the EJB
container wraps it in a
RemoteException
before returning it to the client.
Like stateful session beans, the entity bean instances may be passivated and activated, that is, saved
into the secondary storage and moved back to the memory. The EJB container calls the
ejbPassivate
and
ejbActivate
(both defined in
EntityBean
interface) for EJB passivation and
activation. To maintain synchronization, the
ejbStore
is called before calling
ejbPassivate
so that
the latest version of the EJB instance variable is saved to the database. The
ejbLoad
is called
immediately after calling the
ejbActivate;
thus, the variables of the activated EJB instance are
refreshed with the current state of the entity object.
Business Methods
The business methods contain the business logic you want to encapsulate within the entity bean.
Usually, the business methods do not access the database, allowing you to separate the business logic
from the database-access code. All business methods that can be invoked by clients are defined in the
remote interface. Note that some utility methods that are not meant for the client to use are typically not
defined in the remote interface. Instead, they are normally declared as
private
(or
protected
)
methods and are implemented in the bean class.
Listing 21-5
shows the remote interface of the example
MemberEJB
. In this simple example, only
getters
and
setters
of the instance variables are defined. Because the client can get the primary
key by calling the
context.getPrimaryKey()
method, the
getter
for the primary key is not
necessary. Since the bean should not change its unique identifier during its life cycle, the
setter
for
the primary key is not defined.
Listing 21-5:
Remote interface of MemberEJB
/** MemberEJB Remote Interface
* Note: It does not provide accessor for memberId since it is the
primary key and will
* be accessible by the context.getPrimaryKey() method on the client.
* @author: Andrew Yang
