This performance benefit only accrues if there is an available EJB object in the application
server's pool, so the application server must be tuned to support the expected number of
EJBs an application will simultaneously use. If an application uses an EJB and there are no
pooled instances, the application server will go through the entire lifecycle of creating, ini-
tializing, using, and destroying the EJB object.
The number of objects an application needs depends, of course, on how the application is
used. A typical starting point is to make sure that there are as many objects in the EJB pool
as there are worker threads in the application server, since it is common that each request
will need at most one EJB. Note that EJB pools are per type: if an application has two EJB
classes, the application server will use two pools (each of which can be sized to the number
of threads in the pool).
Application servers differ in the way EJB pools are tuned, but the common case is that there
is a global (or default) configuration for each EJB pool, and individual EJBs that need a dif-
ferent configuration can override that (often in their deployment descriptors). For instance, in
the GlassFish application server, the EJB container uses a default of 32 EJB instances in each
pool, and the size of an individual bean's pool can be set with this stanza in the sun-ejb-
This doubles the maximum size of the bean's EJB pool to 64.
The penalty for creating an EJB pool size that is too big is not usually very large. Unused in-
stances in the pool will mean that GC will be slightly less efficient, but the pool sizes in gen-
eral should be so small that the unused instances don't have a significant impact. The excep-
tion is if the bean holds onto a lot of memory, in which case the GC penalty starts to grow.
However, as can be deduced from the above XML stanza, the common way for an applica-
tion server to manage the pool is to have a steady size in addition to a maximum size. In the
example above, if traffic comes in such that at most 10 instances of this EJB (e.g., from 10
simultaneous requests) are used, only 10 EJB instances will ever be created—the pool will
never begin to approach its maximum of 64.