In this section we outline some of the best practices for session beans that you can use while building the business logic tier for your application.
Choose your bean type carefully. Stateless session beans will be suitable most of the time. Carefully examine whether your application needs stateful session beans, because it comes with a price. If the EJB client lies in the web tier, then using HttpSession may be a better choice than stateful session beans under some circumstances.
Carefully examine interface types for session beans. Remote interfaces involve network access and may slow down your applications. If the client will always be used within the same JVM as the bean, then use a local interface.
If you are using DI, make sure you don’t inject a stateful session bean into a stateless session bean or servlet. Injected EJB instances are stored in an instance variable and are available globally for subsequent clients even if a stateless bean instance is returned to the pool, and an injected stateful bean instance may contain inaccurate state information that will be available to a different client. It’s legal to inject a stateful bean instance to another stateful session bean or an application client.
Separate crosscutting concerns such as logging and auditing using business interceptors (which we discuss in topic 5) instead of spreading them all over the business logic.
Closely examine what kind of data you are storing in the conversation state. Try to use small, primitive instance variables in a stateful bean whenever possible as opposed to large nested composite objects.
Don’t forget to define remove methods in a stateful session bean.
Tune passivation and timeout configurations to find the optimal values for your application.
Summary
In this topic, we examined the various session bean types and how stateless session beans and stateful session beans differ. We looked at the programming rules for both stateless and stateful session beans, and you saw comprehensive examples of both bean types. As you learned, stateless session beans have a simple life-cycle and can be pooled. Stateful beans require instances for each client, and for that reason they can consume a lot of resources. In addition, passivation and activation of stateful beans can impact performance if used inappropriately.
You learned about alternatives for using stateful session beans, and that session bean clients can be either local or remote. We showed you that dependency injection simplifies the use of EJB and saves you from having to perform complex JNDI lookups. Finally, we provided some best practices for developing session beans.
At this point you have all the ammunition necessary to build the business logic of your application using stateless and stateful session beans. In the next topic we’ll discuss how you can build messaging applications with message-driven beans.
