Stateless session bean

The stateless session beans life cycle has two states:

1. does not exist state and
2. the method ready pool

Does not exist

When a bean instance is in the does not exist state, it is not an instance in the momory of the system.In other words, it has not been instantiated yet.

The method ready pool

Stateless bean instances enter the Method-Ready pool, as the container needs them. When the EJB server is first started, it will create a number of stateless bean instances and enter them into the Method-Ready pool, (The actual behavior of the server depends on the implementation). When the number of stateless instances servicing client request is insufficient, more can be created and added to the pool.

Transitioning to the method-ready pool

When an instance transitions from the Does Not Exist state to the Method-Ready pool, three operations are performed on it. First, the bean instance is instantiated by invoking the Class.newInstance() method on the stateless bean class.

Second, the session bean’s setSessionContext(SessionContext context) method is invoked on the bean instance. This is when the instance receives its reference to the EJBContext for its lifetime. The SessionContext reference may be stored in a nonTransient instance field of the stateless session bean.

Finally, the no-argument ejbCreate() method is invoked on the bean instance. Remember that a stateless session bean only has one ejbCreate() method is invoked only once in the life cycle of the stateless session bean, when the client invokes the create() method on the EJB home, it is not delegated to the bean instance.

Stateless session beans are not subject to activation, so they can maintain open connections to resources for their entire life cycle. The ejbRemove() method should close any open resources before the stateless session bean is removed from memory at the end of its life cycle.

Life in the Method-Ready Pool:

Once an instance is in the Method-Ready pool,  it is ready to service client requests. When a client invokes a business method on an EJB object, the method call is delegated to any available instance in the Method-Ready pool. While the instance is executing the request, it is unavailable for use by other EJB objects. Once the instance has finished, it is immediately available to any EJB object then needs it.

Stateless session instances are only dedicated to an EJB object for the duration of the method. When  an instance is swapped in, its SessionContext changes to reflect the context of its EJB object and the client invoking the mehtod. The bean instance may be included in the transactional scope of the client’s request, and it may access SessionContext information specific to the client requested for example, the security and transactional methods. Once the instance has finished servicing the client, it is disassociated from the EJB object and returned to the Method-Ready pool.

Transitioning out of the Method-Ready-Pool

(The death of a stateless bean instance)

Bean instances leave the Method-Ready pool for does Not Exist state when the server no longer needs the instance. This occurs when the server decides to reduce the total size of the Method-Ready pool by removing one or more instance from memory. The process begins by invoking the ejbRemove() method on the instance. At this time, the bean instance should perform any cleanup operations, like closing open resources. The ejbRemove() method is only invoked once in the life cycle of a stateless session bean’s instance, whenit is about to make a transition to the does not exist state. When a client invokes one of the remove() method on a stateless bean’s remote or home interface, it is not delegated to the bean instance. The client’s invocations of this method simply invalidates the stub and releases the EJB object, it notifies the container that the client no longer needs the bean. The container itself invokes the ejbRemove() method on the stateless  instance, but only at the end of the instance’s life cycle.

During the ejbRemove() method, the SessionContext is still available to the bean istance. Following the execution of the ejbRemove() method, the bean is dereferenced and eventually garbage collected.