Pooling

Basics

EJB instances are stored in an in-memory cache and they are not very different from Database Connection pools - so you can think of it as a simple object pool managed by the EJB container. Unlike other features, there are no explicit annotations which affect instance pooling capabilities of session beans. In fact, these are configured in a vendor specific manner (mainly using non portable annotations or deployment descriptors) e.g. weblogic-ejb-jar.xml in Weblogic.

There is virtually no limit to the number of EJB instances which you can tune your container to pool in memory - you are only limited by your hardware resources, specifically the RAM

Common pooling parameters

Different application servers or EJB containers provide various tuning parameters in order to configure these feature. Few of the commonly used ones are

• Initial limit: Configure number of beans which should be ready in the pool initially (after the application starts).

• Upper threshold: Maximum number of bean instances.

• Lower threshold: The EJB container pool count will never fall below this value. Think of it as a SLA (service level agreement)

Benefits

Instance pooling is a key feature of EJBs since it provides key benefits such as

• Scalability: Pool size can be tuned as per load/volume

• Improved performance: Having especially a pre-initialized instance provides significant performance benefits at runtime if the beans have complex/expensive initialization logic

• Automatic resource management: The ability to tune upper and lower pool thresholds helps regulate the resource consumption by the EJB pool

Pooling characteristics of Core EJB components

The core EJB component defining annotations implicitly have some pooling characteristics associated with them. Although these have been covered in one of the previous sections, here is a quick recap

• @Stateless - Pooled beans which do not store state b/w client invocations

• @Stateful - Stores state specific to a client, held in memory by the container and it is passivated to disk or destroyed as per user defined policies (annotations or deployment descriptor XML) and actions

• @MessageDriven - Asynchronous message consumers which are similar to Stateless EJBs in the sense that they are pooled components which do not store state b/w invocations.

• @Singleton - Represents a single in-memory EJB instance. It is not a pooled component like its other counterparts

What's next ?

We'll look at some of concurrency semantics of different EJBs.