DevOps Zone is brought to you in partnership with:

A Software Engineer in the Identity & Access Mgmt domain Passionate about the Java language & platform. Curious by nature Blogger (https://javaee7.zeef.com/abhishek.gupta) Abhishek is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

Stateless EJBs: Pooling and Lifecycle

05.12.2014
| 2250 views |
  • submit to reddit

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-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

Published at DZone with permission of Abhishek Gupta, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Felix G. replied on Wed, 2014/05/14 - 2:31pm

Nice overview., thanks a lot!

Should be expanded to stateful & singleton bean lifecycles.

Abhishek Gupta replied on Sun, 2014/05/18 - 6:49am in response to: Felix G.

Thank you Felix!

I will try to put together something similar for stateless and singleton beans as well

Felix G. replied on Sun, 2014/05/18 - 3:25pm in response to: Abhishek Gupta

 Stateful dude, otherwise you will do the same job twice ;)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.