Entity Bean lifecycle

1. The does not exist state represents entity bean instances that have not been instantiated yet
2. To create a new instance, the container calls the newInstance() method on the entity bean class. This calls your entity bean's default constructor, bringing a new instance into memory. Next, the container associates your entity bean with an entity context object via a callback that you implement, called setEntityContext(EntityContext ctx). Note that this step occurs only when the container wants to increase the available pool of entity bean instances, not necessarily when a client connects.
3. Next, your entity bean is in a pool of other entity beans. At this point your entity bean does not have any entity bean database data loaded into it, and it does not hold any bean-specific resources, such as socket connections. Your bean instance can be used in this mode to find entity data in the database, by servicing a finder method on behalf of a client. Your bean instance can also perform operations not dependent on a particular data instance by servicing an ejbHome() method on behalf of a client. If the container wants to reduce its pool size, it can destroy your bean. The container signals your bean instance that it is about to be destroyed by calling the unsetEntityContext() method on your bean. Once this is done, the container releases any references to your bean, and eventually, the Java garbage collector cleans up the memory your instance had been using. Therefore your unsetEntityContext() method should prepare your bean to be cleaned up, perhaps by releasing any resources your bean had claimed during setEntityContext().
4. When the client wants to create some new database data (say, a new order for goods placed over the Internet), it calls a create() method on your ntity bean's home object. The container then grabs an entity bean instance from the pool, and the instance's ejbCreate() method is called. ejbCreate() initializes the entity bean to a specific data set. For example, if a client calls a create() method to create a bank account, it might pass the bank account holder's name and the initial balance as parameters. Your entity bean's ejbCreate() method would populate its member variables with these parameters. It would also create the corresponding database representation (if you are using bean-managed persistence). Now your bean is in the ready state.
5. While your bean is in the ready state, it is tied to specific data and hence a specific EJB object. If there are other entity bean instances that are views into the same database data, the container may occasionally need to synchronize your bean instance with the underlying database, so that you will always be working with the most recent data. The ejbLoad() and ejb-Store() methods do this; the container calls them as appropriate, based on how you define your transactions
6. Your entity beans can be kicked back into the pool in two ways. If a client calls remove() on the home object, the container will call your instance's ejbRemove(). The underlying database data is destroyed and so, of course, your entity bean instance will become disassociated with the client's EJB object to which it was bound.
7. The second way your bean can return to the pool is if the EJB container decides that your client has timed out, if the container needs to use your bean to service a different client, or if the container is simply running out of resources. At this point, your bean is passivated, and the container calls your ejbStore() method to ensure the database has the most recent version of your in-memory data. Next the container calls your ejbPassivate() method, allowing your bean instance to release held resources. Your bean instance then enters the pool.
8. When the container wants to assign you to an EJB object again, your bean instance must be activated. The container calls your bean's ejbActivate() method, allowing your bean to acquire resources. The container then calls your instance's ejbLoad() method to load the database data into your bean.