If there is a brief traffic spike, the pool might create those 64 instances, but as the traffic
wanes, those additional EJBs will be idle. Once they are idle for 300 seconds, they will be
destroyed and their memory eligible for GC. This minimizes the effect of the pool on GC.
Hence, be more concerned about tuning the steady size of EJB pools than the maximum size.
1. EJB pools are a classic example of object pooling: they are effectively pooled be-
cause they can be expensive to initialize, and because there are relatively few of
2. EJB pools generally have a steady and maximum size. Both values should be
tuned for a particular environment, but the steady size is more important to min-
imize long-term effects on the garbage collector.
Tuning EJB Caches
There is another consideration for stateful session beans, which is that they are subject to
passivation: in order to save memory, the application server can choose to serialize the state
of the bean and save it to disk. This is a severe performance penalty and in most cases is best
Or, frankly, I would recommend that it should be avoided in almost all cases. The usual argu-
ment for passivation is the scenario where the session is idle for hours or days at a time.
When the user does come back (days later), you want her to find her state intact. The prob-
lem with that scenario is it assumes the EJB session is the only important state. Usually,
though, the EJB is associated with an HTTP session, and keeping that session for days is not
recommended. If the application server has a nonstandard feature to store the HTTP session
to disk, then a configuration where both the HTTP session and EJB session data are passiv-
ated at the same time (and for the same duration) may make sense. Even then, though, there
is likely an additional external state as well. (What if the user has in his shopping cart an item
that is no longer available?)
If long-lived state is required, you'll usually need to bypass the normal Java EE state mech-
Stateful beans that are assigned to a session are not held in the EJB pool; they are held in the
EJB cache. Hence, the EJB cache must be tuned so that it is large enough to hold the maxim-