A summarized view (notes) of the Stateless EJB pooling and life-cycle. Useful for newbies . . . . .

EJB Pooling: Quick Overview

• EJB instances are stored in a location known as the EJB Pool – this is nothing but anin-memory cache.
• Stateless EJBs are generally instantiated on-demand i.e. as and when the client invokes a method on the bean.
• However, most application servers also provide a facility wherein they can be configured so that the EJB pool can be populated at start up with certain number of instances e.g. in Weblogic, this can be configured within the weblogic-ejb-jar.xml by stating the exact number in the initial-beans-in-free-pool element.

Pooling benefits

• Improved performance
• Client doesn’t need to wait until the bean is instantiated in order to service the request

Stateless Bean Lifecycle

SLSB States: NON_EXISTENT, INACTIVE, BUSY

NON_EXISTENT – This is a scenario where the bean does not yet exist in the EJB pool (has not been instantiated)

INACTIVE – It is a state where the EJB instance already exists in the EJB pool but is not servicing a client request

BUSY – An EJB instance is summoned in order to service a client request, and as a result it goes into a BUSY state.

An EJB instance is summoned in order to service a client request, and as a result it goes into a BUSY state. An EJB can go into a BUSY state from either INACTIVE or NON_EXISTENT states

SLSB State Transitions

INACTIVE to BUSY – As the name suggests, an inactive bean in the pool was chosen to cater to the client invocation

NON_EXISTENT to BUSY – A fresh EJB instance was created in order to serve a client request

BUSY to INACTIVE

An EJB can go from a BUSY state back to an INACTIVE state i.e. after servicing the client request, the instance goes back to the pool

INACTIVE to NON_EXISTENT

An EJB instance can also be destroyed under certain scenarios by configuring a time out which forces the application server to remove all EJB instances in the pool which have been inactive for a certain time interval. However, app servers do ensure that the EJB instance count does not go below the minimum number of permissible instances (configurable property – read above)

Note: This primarily done in order to conserve the amount of memory which is consumed by the pooled EJBs since they are cached there. If there are a lot of unused instances, they can be removed in order to optimize memory consumption. The container can create new instances on-demand

What happens when a client invokes a method on a Stateless bean?

Scenario 1: A fresh instance of the bean is instantiated by the container.

Why does this happen?

Possible reasons are

• There are no beans in the EJB pool to begin with – the App Server was not instructed to pool a default number of beans on server startup
• All the beans in the EJB pool are busy servicing requests from clients, but the total bean count  in the pool is less than the maximum number of instances which are permissible (a configuration parameter)

Scenario 2: An existing instance of the bean is returned by the container

Possible reasons

• There are certain number of EJB instances available in the pool and they are not in aBUSY state i.e. they are not participating in a servicing a client request. One such instance is just returned by the container
• There were certain number of EJB instances available in the pool but all of them are in a BUSY state and the maximum permissible number of beans in the pool has already been reached. The client application has to wait until one such bean becomes free and is available to cater to the client request

Scenario 3: The client request is not services (receives an exception)

Possible reasons

If the maximum permissible number of beans in the pool has already been reached and the none of the BUSY beans become available within a certain time frame