Java Reference
In-Depth Information
public interface EntityBean extends EnterpriseBean{
public void setEntityContext(EntityContext ctx)
throws EJBException, RemoteException;
public void unsetEntityContext()
throws EJBException, RemoteException;
public void ejbRemove()
throws RemoveException, EJBException, RemoteException;
public void ejbActivate()
throws EJBException, RemoteException;
public void ejbPassivate()
throws EJBException, RemoteException;
public void ejbLoad()
throws EJBException, RemoteException;
public void ejbStore()
throws EJBException, RemoteException;
}
If the EJB container needs to synchronize the instance variables of an entity bean with the
corresponding values stored in a database, it invokes the
ejbLoad
and
ejbStore
methods. The
ejbLoad
method refreshes the instance variables from the database, and the
ejbStore
method writes
the variables to the database. The client may not call
ejbLoad
and
ejbStore
directly. In fact, the
synchronization between the EJB instance variables and the entity-object state is completely
transparent to the client. From the client's point of view, the EJB instance is the same as the entity
object.
If a business method is associated with a transaction, the container invokes
ejbLoad
before the
business method executes. Immediately after the business method executes, the container calls
ejbStore
. Because the container invokes
ejbLoad
and
ejbStore
, you do not have to refresh and
store the instance variables in your business methods. Since the EJB classes rely on the container to
synchronize the instance variables with the database, their business methods should be associated with
transactions.
Normally, the database resides on a different network node from the EJB container in which EJBs are
deployed. Because the implementation of a business method typically accesses the entity object's state,
each invocation of a business method may result in a network trip to the database. If a transaction
includes multiple business invocations, the resulting multiple accesses to the database over the network
may increase the transaction overhead. Many bean developers want to reduce such overhead. To
accomplish this, the EJB architecture allows the entity bean to cache the entity object's state, or part of
the state, within a transaction. Rather than making repeated calls to the database to access the entity
object's state, the EJB instance loads the object's state at the beginning of a transaction and caches it in
its instance variables. The database is not updated until the transaction is ready to commit.
To facilitate such caching, the EJB container invokes the
ejbLoad
method on the instance prior to the
first business method invocation in a transaction. The instance can utilize the
ejbLoad
method to load
the entity object's state, or part of its state, into the instance's variables. Then, subsequent calls to
business methods on the instance read and update the cached state instead of making calls to the
database. When the transaction ends, the EJB container invokes the
ejbStore
method on the
instance. If the previously invoked business methods update the state cached in the instance variables,
calling the
ejbStore
will resynchronize the entity object's state stored in the database with the cached
state.
