EJB containers
An EJB container provides a run-time environment for enterprise beans within the appserver. The container handles all aspects of an enterprise bean's operation within the appserver and acts as an intermediary between the user-written business logic within the bean and the rest of the appserver 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 appserver'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 appserver 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.If you intend to use read-only scenarios, WAS provides an alternate, higher-performance variation of option A entity beans. This caching option is called Multithreaded Read-Only. Similar to standard option A behavior, the EJB container continues to activate the bean just once and leave it active until the EJB container needs space in its active instance cache. However, the EJB container differs from standard option A in the following behaviors:
- It reloads the state of the bean from persistent storage periodically in response to the user invoking a method on it to pick up any changes that may have been made to the persistent store since the last time the bean was loaded. You can configure this function through a Reload Interval setting in the bean’s deployment descriptor. For more information, see Developing read-only entity beans.
- The state of the bean is not written to persistent store by the EJB container at the end of the transaction, nor is the bean's ejbStore() method be invoked.
- The EJB container permits method invocations from more than one client (thread) on the same bean instance. This differs from the standard EJB component for the internals of a bean. You must keep this aspect in mind when developing your bean, and ensure that any logic in the bean’s business methods is overall thread-safe.
- 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.
WAS supports the cloning of stateful session bean home objects among multiple appservers. 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 appserver and can be accessed only by directing requests to that particular appserver. State information for a stateful session bean cannot be maintained across multiple members of a server cluster. However, enabling stateful session bean failover and configuring the EJB container to use memory-to-memory replication does enable stateful session bean failover to be replicated to other servers in the cluster so that failover can occur to the backup server if the primary server for a stateful session bean stops for some reason. For more information about stateful session bean failover, see Stateful session bean failover for the EJB container.
By default, an EJB container runs in the quick start mode. The EJB container startup logic delays the loading and processing of all EJB types except Message Driven Beans (because they must exist before messages are posted for them), Startup Beans (which must be processed at server startup time), and those EJB types specified to initialize at server start. For more information about disabling quick start for EJB types, see Change enterprise bean types to initialize at application start time using the Application Server Toolkit.
All other EJB initialization is delayed until the first use of the EJB type. When using Local Interfaces, the first use is when you perform an InitialContext.lookup() method for the type. For Remote Interfaces, it is when you call the first method on an EJB or its Home.
For more information about EJB containers, see Enterprise beans: Resources for learning.
Related concepts
Enterprise beans
Related tasks
Manage EJB containers
Related Reference
Enterprise beans: Resources for learning