Head First EJB

Your job for passivation: make your state passivatable!

When ejbPassivate() completes, every non-transient instance variable MUST be a reference to one of the following:

• a Serializable object

• a null value

• a bean’s remote component or home interface, even if the stub class is not Serializable (in other words, you don’t have to worry about it!)

• a bean’s local component or home interface, even if it’s not Serializable (again, you don’t have to worry)

• a SessionContext object, even if it’s not Serializable

• the bean’s special JNDI context, or any of its subcontexts

• the UserTransaction interface (something you can get from your SessionContext—we’ll see that in the transactions chapter)

• a resource manager connection factory (like, an instance of javax.sql.DataSource)

Note

You have to know these for the exam.

You might see a question that shows you a class and an ejbPassivate() method and asks you if it would work or not.

If the method is empty, you have to look at the instance variables to see if they’re all OK as they are.

Implementing ejbActivate() and ejbPassivate()

ejbPassivate()

Make sure your instance variables are ready for passivation. Most of the time, you probably won’t have any code in ejbPassivate(), simply because all of your instance variables meet the criteria defined on the previous page (e.g. reference to a SessionContext, or a bean’s component interface, or a Serializable object, etc.).

ejbActivate()

Reacquire your non-Serializable resources, or do whatever it takes to restore your state for use. If you’re running in ejbActivate(), there can be only one reason: the client called a business method. So in your ejbActivate() method, you must make sure you get ready for the business method call that’s about to happen.Chances are, this method will be empty, for the same reason as ejbPassivate(). But if you did null out non-Serializable references, then ejbActivate() is the place to get them back.

public void ejbActivate() {
  try {
   connection = myDataSrc.getConnection();
  }catch (Exception ex) {...}
}

Note

now we have to get the JDBC connection back again. Notice that the DataSource did not have to be restored, because it’s one of the things on the Container’s “approved list”. (Because it’s a resource manager connection factory, and the Container is required to passivate it.)

There are no Dumb Questions

Q:	Q: Can’t you just mark your non-Serializable variables transient? Isn’t that what transient is for?
A:	A: You could, yes, because the Container is required to follow the rules for Serialization when it passivates a bean (even if the Container chooses to use something other than serialization to get the job done). But... there’s a little teeny comment in the spec which says that there’s an exception to the rule that passivation behave just like serialization. The exception is that while serialization is required to bring back transient fields with default values, passivation doesn’t guarantee that! What does this mean? Think about it. It means you can’t rely on transient to give you back your defaults, so after activation, you could end up with, well, anything in a variable that’s marked transient. So, you are free to use transient, and it can make passivation more efficient, but the implication is—reset your transient variables yourself, in ejbActivate().
Q:	Q: What if I have a non-Serializable value that I really need to maintain during passivation? If I can’t save it, how will I know what to set it back to in ejbActivate()?
A:	A: This is a classic serialization issue, not specific to passivation. The usual trick is to interrogate the non-Serializable object to get all the important state out of it, and stick that state into instance variables that are Serializable. Then during ejbActivate(), use the values you were able to save to reconstruct the non-Serializable object so that it’s identical to the one you had before passivation. For example, imagine you have a Dog bean with a Collar variable, and the Collar isn’t Serializable. In ejbPassivate(), call getters on the Collar to retrieve the values that matter (like getColor(), getSize(), etc.). Save those values in instance variables in the bean, then in ejbActivate() instantiate a new Collar and use the Collar attributes you saved as arguments to setters on the new Collar object.

Sharpen your pencil

You’re responsible for making sure that when ejbPassivate() completes, your instance variables are in one of the states we listed a couple of pages ago. Don’t look now! See if you can work out which of these will be safely passivated...

	reference to a java.net.Socket object
	reference to a javax.sql.DataSource
	reference to a bean’s Remote component interface
	reference to a bean’s JNDI context
	reference to a java.sql.Connection
	reference to a javax.ejb.SessionContext object
	a transient variable with a null value
	a non-transient, Serializable variable with a null value
	a transient variable with a non-null value
	a non-transient, non-Serializable variable with a null value
	a non-transient, non-Serializable variable with a non-null value[a]
[a] We were going for a personal best (PB) in the number of times in which we could use the word ‘non’ in a single statement.

WARNING:

A stateful session bean will NEVER be passivated while the bean is still in a transaction!

The spec lets you begin a transaction in one method of a stateful session bean, but end the method without ending the transaction. This is almost always a really stupid thing to do. For starters, you could never guarantee that just because a client calls the method that begins the transaction, the client will at some point call the method that ends the transaction (in either a commit or rollback). But the main reason is that the longer your transactions, the better your chances of bringing your server to its knees (and that holds regardless of the bean type). For stateful session beans, leaving a transaction open means the bean will not be passivated, no matter how long it’s been since the client did anything with it. We’ll look at this more in the transactions chapter, but for now, understand that stateful beans in a transaction won’t be passivated!