Java Reference
In-Depth Information
3.2.2. Stateless session bean pooling
EJB pooling is a complex, seldom documented, and poorly understood topic, so it deserves
proper coverage here, particularly stateless session bean pooling. The basic idea behind in-
stance pooling is to reuse a predefined number of bean instances to service incoming re-
quests. Whenever a request arrives for a bean, the container allocates a bean. When the
stateless session bean's method returns, the bean is placed back into the pool. Thus, a bean
is either servicing a request or waiting for a request in the pool. Pools have an upper bound.
If the number of concurrent requests for a stateless session bean exceeds the size of the
pool, the requests that can't be handled are placed in a queue. As soon as instances become
available in the pool, they're assigned to a request in the queue. No instances can hang
around the pool forever—they're eventually timed out if they sit idle for too long. A pool
can also have a lower bound to specify the minimum number of instances it must always
have.
The pool provides several important benefits. Having a minimum set of beans in the pool
ensures that there are objects ready to service a request when one arrives. This reduces
the overall time to service a request by creating beans beforehand. Reusing bean instances
when possible instead of frivolously discarding them also means less total object creation
and destruction for the application, which saves time for the JVM garbage collector. Lastly,
specifying an upper limit of the pool acts as an effective bandwidth-throttling mechan-
ism. Without an effective bandwidth-throttling mechanism, a machine could be easily over-
whelmed with a sudden burst of concurrent requests. Bandwidth throttling ensures that the
server performs gracefully even under heavy load. Dynamic pools, bandwidth throttling,
and request queuing are essential elements of the proven staged event-driven architecture
(SEDA) model central to highly concurrent, well-conditioned, dependable, scalable, mod-
ern internet services.
Pooling isn't a standard feature mandated by the EJB specification. Like clustering, pooling
is left optional but most application servers support it. Containers compete on scalability
and performance-tuning features, so each container provides slightly different parameters
for pooling as well as different defaults. For example, these are some of the pooling settings
available in the GlassFish server:
•
Initial and minimum pool size—
The minimum number of beans to appear in the
pool. The default is 0.
•
Maximum pool size—
The maximum number of beans that can be present in the
pool. The default is 32.
