Head First EJB

We have to look at the transitions

Now that you’ve seen the overall state diagram, we have to drill down and find out what really happens (and why) when a stateful session bean transitions from one state to another.

Moving from does not exist to method ready

Moving from method ready to passivated and vice-versa

Moving from passivated or method ready to does not exist

There are no Dumb Questions

Q:	Q: If it’s so common to leave the methods empty, why don’t they have adapter classes like they have for event handlers—that implement all the methods from the interface? Is there any reason why your bean class can’t extend a class that implements the SessionBean interface?
A:	A: The API doesn’t have adapter classes for SessionBean implementations (i.e. a class that implements all of the methods). But there’s no reason you can’t make one yourself. Keep in mind, though, that with real-world beans you probably will have code in one or more of the methods. And you might even be working with a bean-aware IDE that puts the methods in for you anyway. Still, it might be handy to make yourself a generic bean that you typically extend from, that has all of the methods from SessionBean. With stateless beans, especially, you have to implement ejbActivate() and ejbPassivate(), even though they’ll never be called! (Stateless beans are never passivated; you’ll see more on that later in the chapter.)
Q:	Q: I just remembered that I read somewhere that enterprise beans don’t support inheritance! What’s that about?
A:	A: Ah... a common misconception. Well, sort of. EJB supports regular Java class inheritance, but has no concept of bean inheritance. And now you’re asking, “What the heck is the difference?” You already know what class inheritance is, it’s the thing you do in Java when one class extends another. And you can do that with a bean, just like any other class. But bean inheritance (if it were supported) would mean that a bean class could extend another bean class and inherit not just the class’ inheritable members, but also its beanness. What kind of beanness might be inheritable? (Just in case they do decide to support this in the future, which is a possibility. Regular old non-enterprise beans do support bean inheritance.) One idea might be to have your bean subclass inherit some of the deployment descriptor settings of its superclass, and then override the ones it wants to change with a much smaller, incomplete deployment descriptor. That might be cool; we’re not sure. But right now, it’s just our little fantasy. In the meantime, go ahead and let your bean extend another class, if it makes sense for your OO design.

Sharpen your pencil

For the exam, you have to know exactly which methods are in the SessionBean interface, so now is a good time to start memorizing them. See if you can remember the name of the method that matches the behavior described. We’ve included some pretty big hints here because it’s your first time, but the mock exam questions will be much less obvious...

1. This method is called when the client tells the Container that he’s done using a stateful session bean. The bean is NOT happy:

___________________________________

2. This method is called when the bean is put to sleep to temporarily conserve resources:

___________________________________

3. This method is called when the previously-sleeping bean is called back to active duty to service a business method:

___________________________________

4. This method is called near the beginning of the bean’s life, when the Container hands the bean a reference to the bean’s special link to the Container:

___________________________________

Sharpen your pencil

Fill in the missing methods. Don’t worry if you don’t get the name exactly right; just try to work out what happens at each of the transitions in the stateful session bean state diagram.

Note

You have to know this lifecycle!

If you take the exam, you’ll thank us for beating it to death because you really must know it backwards and forward.

But even as a bean developer, this is so fundamental to writing your bean code that you DO want to have this memorized. This isn’t like one of those API memorization questions where you think, “Isn’t that what the docs are for?”

Even if you have an IDE that puts the container callbacks into your code for you, you still have to know what they mean and what you should or should not do in each one.