Head First EJB

Implementing the container callbacks

This AdviceBean code is completely legal. It compiles and runs. Right now, we don’t need anything in the callback methods, because the bean’s business logic doesn’t depend on anything else that happens at other times in the bean’s life. You’ll notice that we are saving the SessionContext parameter we get from the setSessionContext() container callback, but we aren’t using it in this code. Later in this chapter, you’ll learn why you might want to assign the context to an instance variable, and the circumstances under which you would put code in each of these callback methods.

When are container callbacks invoked?

For stateful session beans, when the bean transitions from one state to another.

does not exist	Before a bean is a bean (or even an object) it does not exist. The spec makes a big point of this, just in case there’s any confusion about something existing before it exists. So the state of non-existence is indeed a state that a bean can be in, even though it does not yet exist. When a session bean moves out of this state, the bean’s constructor runs, then setSessionContext(), and finally the ejbCreate() method. This is also the state a bean returns to after any one of these things occurs: bean times out, bean throws a system exception, or a client calls remove(). The bean will get an ejbRemove() call if the client calls remove() or times out while in the method ready (active) state.
method ready	A bean in the method ready state is either executing a client’s method, or waiting for the client to make another business method call. A stateful bean might or might not be in an active transaction while in this state (depends on the deployment transaction settings and the caller’s transaction status), but if the bean is in a transaction, the bean cannot be passivated.
passivated	A passivated bean is temporarily saved in some kind of secondary storage, to conserve resources between client calls. Passivation might be serialization, although the Container can use anything it wants as long as it behaves like serialization (with one small exception we’ll see later in this chapter). Although a passivated bean is no longer an active object on the heap, the Container will reactivate the bean (calling ejbActivate()) when the client calls a business method. If a passivated bean times out, the bean will simply die, without first being reactivated.