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 bean instance’s setSessionContext(SessionContext context) method is invoked. This is when the instance receives its reference to the EJBContext. The SessionContext reference may be stored in a nontransient instance field of the stateless session bean. Finally, the bean’s no-argument ejbCreate( ) method is invoked. Remember that a stateless session bean has only one ejbCreate( ) method, which takes no arguments. ejbCreate( ) is invoked only once in the life cycle of the stateless session bean.

Stateless session beans are not subject to activation, so they can maintain open connections to resources for their entire life cycles.^[30] The ejbRemove( ) method should close any open resources before the stateless session bean is evicted from memory at the end of its life cycle. You’ll read more about ejbRemove( ) later in this section.

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 that needs it. This is slightly different from the instance pool for entity beans described in Chapter 10. In the entity instance pool, a bean instance might be swapped in to service an EJB object for several method invocations. Stateless session instances are typically dedicated to an EJB object only for the duration of a single method call.

When an instance is swapped in, its SessionContext changes to reflect the context of the EJB object and the client invoking the method. 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 request: 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.

Stateless session beans are not subject to activation and never have their ejbActivate( ) or ejbPassivate( ) callback methods invoked. The reason is simple: stateless instances have no conversational state to be preserved. (Stateful session beans depend on activation, as we’ll see later.)

Clients that need a remote or local reference to a stateless session bean begin by invoking the create( ) method on the bean’s EJB home:

Object ref = jndiConnection.lookup("ProcessPaymentHomeRemote");
ProcessPaymentHomeRemote home = (ProcessPaymentHomeRemote)
    PortableRemoteObject.narrow(ref,ProcessPaymentHomeRemote.class);

ProcessPaymentRemote pp = home.create( );

Unlike the entity bean and stateful session bean, invoking the create( ) method does not result in a call to the bean’s ejbCreate( ) method. In stateless session beans, calling the EJB home’s create( ) method results in the creation of an EJB object for the client, but that is all. ejbCreate( ) is invoked only once in the life cycle of an instance: when it is transitioning from the Does Not Exist state to the Method-Ready Pool. It is not reinvoked every time a client requests a remote reference to the bean. Stateless session beans are limited to a single no-argument create( ) method because there is no way for the container to anticipate which create( ) method the client will invoke.

Bean instances leave the Method-Ready Pool for the Does Not Exist state when the server no longer needs them; that is, when the server decides to reduce the total size of the Method-Ready Pool by evicting one or more instances from memory. The process begins by invoking the ejbRemove( ) method on the instance. At this time, the bean instance should perform any cleanup operations, such as closing open resources. As with ejbCreate( ), ejbRemove( ) is invoked only once: when the bean is about to transition to the Does Not Exist state. When a client invokes one of a stateless session bean’s remove methods, the bean’s stub is invalidated, and the container is notified that the bean is no longer needed, but the bean itself is not removed. The container itself invokes ejbRemove( ) on the stateless instance at the end of the instance’s life cycle—when it decides it no longer needs to maintain this instance in the pool. Again, this is different from both stateful session beans and entity beans, which suffer more destructive consequences when the client invokes a remove method. During the ejbRemove( ) method, the SessionContext and access to the JNDI ENC are still available to the bean instance. Following the execution of the ejbRemove( ) method, the bean is dereferenced and eventually garbage collected.