Head First EJB

Passivation: a stateful bean’s chance at scalability...

When the Container decides a stateful bean is wasting resources, it’ll call the bean’s ejbPassivate() method and then save the bean into temporary storage.

Why do you care about passivation details?

Because the Container uses a special set of rules (nearly identical to Serialization) to passivate your bean, and it’s your job to make sure your instance variables are in a state that works for passivation. And it’s just a tiny bit more subtle than simply making non-Serializable values transient.

Lifecycle overview: bean passivation/activation

1. Client doesn’t call any methods for a while, so container calls ejbPassivate() on the bean.

   

2. Container calls ejbPassivate() on the bean, then saves the bean to temporary storage (either through serialization or something like it).

   

3. Client calls a business method, so container activates the bean (through something like deserialization), calls ejbActivate(), then invokes the business method (getAdvice()) on the bean.

   

There are no Dumb Questions

Q:	Q: How does the Container know when to passivate a bean?
A:	A: The Container looks for inactivity. If the client hasn’t been doing anything for some period of time, the Container can choose to passivate the bean. If it needs to.
Q:	Q: Gee... can you be any more non-committal? How long is “some period of time” and what determines whether the Container ‘needs to’ passivate the bean?
A:	A: There is nothing in the spec that says you’re allowed to tune the parameters for the Container’s passivation decisions. But... many containers do give you a way to set a variety of values. The decision might be based on availability of resources, like, “passivate stateful session beans only when available RAM hits this level...” or, “passivate beans only when the number of active stateful session beans reaches...” And you might be able to set the inactivity value for the amount of elapsed time at which the Container should passivate.
Q:	Q: What if the client crashes? Can the server tell? Is there any kind of distributed garbage collection or leasing like there is with RMI? Or is the server really just basing everything on inactivity?
A:	A: According to the spec, there is no guarantee of distributed garbage collection, which means you should assume that it isn’t happening. Part of the reason is because an EJB client could (at least in theory) be a CORBA client rather than a Java RMI client. So the whole concept of RMI’s distributed garbage collection wouldn’t apply. And just a quick off-path here: distributed garbage collection (dgc) or distributed leasing are ways in which a server can figure out if a client has (with dgc) nulled out their reference to the stub, or (with leasing) if the client has simply gone away, either by shutting down the app, crashing, or disconnecting from the network. The bottom line is that you have to assume that the EJB server doesn’t support this, so you’re stuck with inactivity and perhaps some kind of LRU (Least Recently Used) algorithms for selecting who should be passivated if resources become scarce and the Container needs to bring down some beans.

Relax

There’s nothing on the exam about vendor-specific passivation settings or behavior.

The only thing on the exam about passivation is what you’re responsible for as a Bean Provider—getting your instance variable values in a passivatable state (we’ll talk about that next). Nothing about passivation goes into the deployment descriptor, so you don’t need to know how passivation parameters are set for any particular server.