Building business logic with session beans - EJB 3 in Action - page 103

Choosing session data appropriately
Stateful session beans can become resource hogs and cause performance problems if
they're not used properly. Because the container stores session information in memory, if
you have thousands of concurrent clients for your stateful session bean, you may run out of
memory or cause excessive disk thrashing as the container passivates and activates beans.
Consequently, you have to closely examine what kind of data you're storing in the con-
versation state and make sure the total memory footprint for the stateful bean is as small
as possible. For example, be careful of storing objects with very deep dependency graphs,
byte arrays, or character arrays.
If you cluster stateful session beans, the conversational state is replicated between different
instances of the EJB container. State replication uses network bandwidth. Storing a large
object in the bean state may have a significant impact on the performance of your applic-
ation because the container will spend an excessive amount of time replicating objects to
other instances to ensure high availability. We'll discuss EJB clustering further in chapter
15 .
Tuning passivation
The rules for passivation are generally implementation-specific. Improper use of passiva-
tion policies (when passivation configuration is an option) may cause performance prob-
lems. For example, the Oracle Application Server passivates bean instances when the idle
time for a bean instance expires, when the maximum number of active bean instances al-
lowed for a stateful session bean is reached, and when the threshold for JVM memory is
reached. You have to check the documentation for your EJB container and appropriately
set passivation rules. For example, if you set the maximum number of active instances al-
lowed for a stateful session bean instance to 100 and you usually have 150 active clients,
the container will continue to passivate and activate bean instances, thus causing perform-
ance problems.
Remove stateful session beans
You can go a long way toward solving potential memory problems by explicitly removing
the bean instances that are no longer required rather than depending on the container to
time them out. Thus, each stateful session bean should have at least one method annotated
with @Remove and then invoke this method at the end of the bean's workflow. Now that
you have a handle on stateful session beans, let's delve into singleton beans.