EJB containers
An Enterprise JavaBeans (EJB) container provides a run-time environment
for enterprise beans within the application server. The container handles
all aspects of an enterprise bean's operation within the application server
and acts as an intermediary between the user-written business logic within
the bean and the rest of the application server environment.
One or more EJB modules, each containing one or more enterprise beans,
can be installed in a single container.
The EJB container provides many services to the enterprise bean, including
the following:
- Beginning, committing, and rolling back transactions as necessary.
- Maintaining pools of enterprise bean instances ready for incoming requests
and moving these instances between the inactive pools and an active state,
ensuring that threading conditions within the bean are satisfied.
- Most importantly, automatically synchronizing data in an entity bean's
instance variables with corresponding data items stored in persistent storage.
By dynamically maintaining a set of active bean instances and synchronizing
bean state with persistent storage when beans are moved into and out of active
state, the container makes it possible for an application to manage many more
bean instances than could otherwise simultaneously be held in the application
server's memory. In this respect, an EJB container provides services similar
to virtual memory within an operating system.
Between transactions, the state of an entity bean can be cached. The EJB
container supports option A, B, and C caching.
- With option A caching, the application server assumes that the entity
bean is used within a single container. Clients of that bean must direct their
requests to the bean instance within that container. The entity bean has exclusive
access to the underlying database, which means that the bean cannot be cloned
or participate in workload management if option A caching is used.
- With option B caching, the entity bean remains active in the cache throughout
the transaction but is reloaded at the start of each method call.
- With option C caching (the default), the entity bean is always reloaded
from the database at the beginning of each transaction. A client can attempt
to access the bean and start a new transaction on any container that has been
configured to host that bean. This is similar to the session clustering facility
described for HTTP sessions in that the entity bean's state is maintained
in a shared database that can be accessed from any server when required.
This product supports the cloning of stateful
session bean home objects among multiple application servers. However, it
does not support the cloning of a specific instance of a stateful session
bean. Each instance of a particular stateful session bean can exist in just
one application server and can be accessed only by directing requests to that
particular application server. State information for a stateful session bean
cannot be maintained across multiple members of a server cluster.
For more information about EJB containers, see "Resources for learning."

Enterprise beans

Managing EJB containers

Enterprise beans: Resources for learning
Searchable topic ID:
cejbecnt
Last updated: Jun 21, 2007 4:55:42 PM CDT
WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cejb_ecnt.html