Summary

This chapter has covered some of the major issues of session-bean design and implementation. We have seen that:

• Stateless session beans are usually the best way to implement business logic when we choose to use EJBs.

• Stateful session beans should only be used when there is no alternative to a stateful model in the EJB tier, as they consume more resources in the EJB container than SLSBs and do not provide truly robust state management. (In particular, application servers are likely to find it more difficult to replicate changes to SFSBs in a cluster than to replicate changes to HttpSession state.) We've looked at some techniques that may allow us to use stateless session beans in place of stateful session beans.

• The Session Façade design pattern can be used to enhance performance, simplify implementation, and maximize design flexibility, especially in distributed applications. It is usually the best way for remote clients to access the EJB tier.

• The EJB Command design pattern is an alternative to the Session Façade pattern, based on moving code from client to server and executing it on the server.

We've built on our knowledge of EJB container services by considering:

• The EJB container's behavior when an EJB throws an exception. While application exceptions (checked exceptions other than java.rmi.RemoteException) are thrown to the EJB client as in ordinary Java method invocation, without any intervention by the EJB container, system exceptions (java.rmi.RemoteException and unchecked exceptions) cause the EJB container to mark the current transaction for rollback and discard the offending EJB instance. This behavior can be used to simplify error handling, meaning that we don't need to catch fatal runtime exceptions, but can simply leave the EJB container to deal with them. It also means that if we want the current transaction rolled back in the event of an application exception, we must use the setRollbackOnly() method in application code, as the EJB container will take no action.

• The meaning of the six transaction attributes for EJB CMT and how they affect the behavior of session bean methods.

We've looked at the "Business Methods Interface" pattern, a simple coding technique that can prevent errors by ensuring that an EJB's component interface and implementation class are always in sync. This involves making both component interface and bean implementation class implement a "business methods interface", enabling the compiler to check that method signatures match.

We've discussed the following good session bean implementation practices:

• Use session beans to delimit transactions.

• In distributed applications, execute a complete use case in each method on a remote interface if possible.

• When implementing session beans, cache the results of JNDI lookups, such as EJB home references and DataSource objects. When implementing SLSBs, cache resources and data on behalf of all clients.

The following recommendations apply to stateful session beans:

• If deploying applications using SFSBs in a clustered environment, read your application server documentation regarding stateful session bean behavior in a cluster closely. Different servers have different behavior that can affect the performance and even the viability of using SFSBs. (For example, is session state replicated after completed transactions, or after each method call? Is there any way of ensuring fine-grained replication, rather than replication of the whole of an SFSB's state every time?)

• Keep transactions short, as SFSB conversational state is likely to be most vulnerable during transactions (although this will depend on your EJB container).

• Don't use the javax.ejb.SessionSynchronization interface. Try to manage transactions in individual methods, relying on EJB CMT.

• Remember to leave instance data in a legal state after the ejbPassivate() method and in a usable state after the ejbActivate() method.

• Synchronize client code if necessary to protect SFSBs against illegal concurrent calls.

In the next chapter we'll move on to overall application infrastructure, including some generic EJB superclasses that can simplify development and reduce the likelihood of errors when implementing session beans and message-driven beans.