3 . An instance is stored in memory awaiting method invocations.
4 . A client executes a business method through the business interface.
5 . The container waits for subsequent method invocations and executes them.
6 . If the client remains idle for a period of time, the container passivates the bean in-
stance (if the container supports passivation). The bean gets serialized out to disk.
7 . If the client invokes a passivated bean, it's activated (the object is read in from
8 . If the client doesn't invoke a method on the bean for a period of time, the bean is
9 . If the client requests removal of a bean instance and it's presently passivated, it'll
be activated, and then the bean will be destroyed and reclaimed by garbage collection.
Like a stateless session bean, the stateful session bean has a number of lifecycle callback
methods. We have the same callback methods available in stateless session beans, corres-
ponding to bean creation and destruction, as well as two additional callbacks related to pas-
sivation/activation. The callbacks available on stateful session beans are as follows:
• @PostConstruct— This is invoked right after the default constructor has ex-
ecuted and resources have been injected.
• @PrePassivate— This is invoked before a bean is passivated; that's before the
bean is serialized out to disk.
• @PostActivate— This is invoked after a bean has been read back into memory
but before business methods are invoked from a client.
• @PreDestroy— This is invoked after the bean's timeout has expired or the client
has invoked a method annotated with @Remove . The instance will be subse-
quently released to the garbage collector.
These callback annotations may be placed on multiple methods—you're not limited to one
per class. The point of the PrePassivate callback is to give the bean a chance to pre-
pare for serialization. This may include copying nonserializable variable values into seri-
alizable variables and clearing unneeded data out of those variables to save disk space.
Most often the prepassivation step consists of releasing heavy-duty resources like open
databases, messaging, and socket connections that can't be serialized. A well-behaved bean