Client's View

Yesterday, you saw how to use JNDI to obtain a reference to a Session bean home and how to obtain a Session bean by calling the appropriate create() method. Now that you have a full understanding of how Session beans work, there are a few other points that are worth appreciating.

First, if your client has a reference to a stateless Session bean, although it should call remove() when it is finished with the EJB, this method call doesn't actually do particularly much. In particular, it won't release any bean resources itself, as shown clearly by the state chart diagrams in Figure 5.3. What this will do is allow the EJB container to remove the EJBObject proxy for the bean.

Conversely, calling create() for a stateless Session bean doesn't necessarily cause ejbCreate() to be called on the underlying bean, although the client will have a reference to an EJBObject after making this call.

One benefit of stateless beans over stateful is that they are more resilient. That is, if the client invokes a method on a stateless bean and it throws an exception, the client can still use their reference to try again. The client does not need to discard the reference and obtain a new one from the home interface. This is because, behind the scene, the EJB container will have discarded the bean that threw the exception, but can simply select another bean from the pool to service the client's retry attempt. This is safe to do because the stateless Session beans have no state. Of course, it is possible that the retry attempt might fail; it would depend on the underlying cause of the exception.

In contrast, if a stateful Session bean throws an exception, the client must obtain a new Session bean reference and start its conversation over again. This is because the EJB container will have discarded the Session bean that threw the exception, discarding all the client's conversational state in the process.

Sometimes, a client may end up having two references to a Session bean. It may have obtained them both from other method calls, for example. More precisely, the client will have two RMI stubs to Session beans. If the client wants to determine whether these two stubs refer to the same Session bean, it should not call the equals() method. This almost certainly will not return true. Instead, the client should call isIdentical(EJBObject) on the reference. This indicates whether both stubs refer to the same Session bean. Note that two references to the same stateless Session bean will always return true, because—at least conceptually—there is only a single instance (see EJB specification, section 7.5.6).

Earlier today, you saw the different types of exceptions that a bean can throw. If a bean throws an application exception, the EJB container will propagate it back to the client. If the bean throws an EJBException (representing a system exception), the EJB container will throw a java.rmi.RemoteException in turn.

For the client, any RemoteException represents a severe problem. It doesn't really matter to the client if the RemoteException has arisen because of a network problem or because of a problem with a bean. Either way, it will be unable to recover the problem.

Table 5.1 lists the system exceptions shown in Figure 5.5 and indicates how each is raised and thrown. As you will see, the majority are raised when the EJB container itself has detected a problem with either transactions or security. You will learn more about transactions on Day 8, and more about security a week later on Day 15, “Security.”

If you are wondering what BMP Entity beans are, the phrase is an abbreviation of “bean-managed persistence Entity beans.” You'll be learning about those tomorrow.