O'Reilly logo

Head First EJB by Bert Bates, Kathy Sierra

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Your job for passivation: make your state passivatable!

image with no caption

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.).

image with no caption

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.)

image with no caption

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!

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required