Java Reference
In-Depth Information
should ensure that heavy-duty resources are both closed and explicitly set to null before the
actual passivation (serialization) takes place.
From the perspective of a bean instance, there isn't much of a difference between being
passivated and being destroyed. Very often one method is annotated with both the
@PrePassivate
and
@PreDestroy
annotations. The same thing is often done for
@PostConstruct
and
@PostActivate
. In the case of both of these annotations,
heavy-duty resources are being either established or reestablished.
Listing 3.2
is a good ex-
ample because the
java.sql.Connection
object can't be serialized and must be rein-
stated during activation.
One caveat: you're not responsible for reestablishing connections of injected resources.
When a bean is activated, the container will reinject all of the resources. Also, any refer-
ences to other stateful session beans will be reestablished. In these callback methods, you
need to install or break down only the resources that you're manually managing.
In addition to these callbacks, one or more methods can be annotated with
@Remove
. This
annotation informs the container that when the method exits, the stateful session bean is
to be released. The client no longer needs and will no longer access the stateful session
bean. If the client attempts to access the bean afterward, an exception will be thrown. As in
the case of the
BidderAccountCreator
, multiple methods will most likely be annot-
ated with
@Remove
. One method commits the contents of the workflow, whereas the other
method cancels the changes. Failure to remove stateful beans will have a serious impact on
server performance. The problem might not be apparent with a small number of clients, but
it will become critical as more people request stateful session beans over time.
3.3.8. Using stateful session beans effectively
There's little doubt that stateful session beans provide extremely robust business lo-
gic-processing functionality if maintaining a conversational state is an essential application
requirement. In addition, EJB 3 adds extended persistence contexts specifically geared to-
ward stateful session beans (discussed in
chapter 10
). This significantly increases their cap-
abilities. Nonetheless, there are a few things to watch out for while using stateful session
beans. First, most of the best practices for stateless session beans apply to stateful session
beans. In addition, stateful beans have the following factors that you should consider.
