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

3.3.1. When to use stateful session beans
Stateful session beans are ideal for multistep, workflow-oriented business processes. To
understand what this means, think of the new envelope wizard in Microsoft Word. If you
want to create a new envelope, the wizard will guide you through the steps to select a par-
ticular style of envelop and enter the destination address and return address. Real business
workflows are a great deal more complex with conditional steps and additional requests to
back-end databases and message queues.
Multistep, workflow-oriented business processes don't necessarily require stateful session
beans. For example, you can use plain CDI managed beans at the web tier to manage state.
As we'll discuss in chapter 12 , CDI and JSF have a rich set of scopes that's unmatched
in EJB. As a rule of thumb, you should use stateful session beans if your workflow con-
tains business logic that's not appropriate for the web tier. Like other EJBs, stateful session
beans bring a few important features to the table. Stateful session beans are thread-safe and
participate in transactions as well as container security. Stateful session beans can also be
accessed remotely via RMI and SOAP as well as REST. Finally, the container manages
them for you—stateful session beans are automatically passivated when no longer in use
or destroyed after an in-activity time-out is triggered. Many of the same reasons for using
stateless session beans also apply to stateful session beans.
3.3.2. Stateful session bean passivation
One of the great benefits of stateful session beans is that the container will archive stateful
session beans if they haven't been used for a while. There are a variety of reasons why a
stateful session bean might not have been used in a while; for instance, the user might have
wandered away from their desk or might have switched to another application. The reas-
ons vary, but obviously the server should notice that a bean hasn't been accessed in a while
and take steps to free up underutilized resources. The container employs a technique called
passivation to save memory when possible.
Passivation means moving a bean instance from memory to disk. The container accom-
plishes this task by serializing the entire bean instance. Activation is the opposite of pas-
sivation and is done when the bean instance is needed again, as shown in figure 3.7 . The
container activates a bean instance by retrieving it from permanent storage and deserializ-
ing it. As a result, all bean instance variables must either be a Java primitive, implement
java.io.Serializable , or be marked as transient .