Client Applications

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

Design Considerations

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 much. In particular, it won't release any bean resources itself. 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 beans is that, to the client, they appear to be more resilient. If the client invokes a method on a stateless bean and it throws an exception, the client can still use its 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 scenes, although the EJB container will have discarded the bean that threw the exception, it can simply select another bean from the pool to service the client's retry attempt.

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.

Exception Handling

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, in turn, throw a java.rmi.RemoteException.

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 unlikely to be able to recover.

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.

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.