- What Is Conversational State?
- What Are Session Beans?
- Session Bean Files
- Characteristics of Session Beans
- Types of Session Beans
- Session Bean Methods
- Life Cycle of Session Beans
- Comparing Stateless and Stateful Session Beans
- Best Practices
- Summary
- Q&A
- Quiz
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
Comparing Stateless and Stateful Session Beans
Stateless session beans do not maintain state associated with any client. Each stateless session bean can server multiple clients.
Stateful session beans maintain the state associated with a client. Each stateful session bean serves exactly one client.
Stateless session beans are intended to be simple and lightweight; that is, they are easy to develop with low runtime resource requirements on the server. If required, any state is maintained by the client, and thereby makes the server highly scalable. Because no state is maintained in this enterprise bean type, stateless session beans aren't tied to any specific client. Therefore, any available instance of a stateless session bean can be used to service another client.
The container creates an implicit identity for a stateful session bean to manage its passivation and activation phases. On the other hand, the container doesn't create any identity for a stateless session bean.
The number of stateful session beans is equal to the number of active clients, whereas a small number of stateless session beans can be used to satisfy a large number of clients.
Stateful session beans provide easy and transparent state management on the server side. Because state is maintained in this enterprise bean type, the application server manages client-bean pairs. In other words, each instance of a given enterprise bean is created on behalf of a client, and is intended to be a private resource to that client (although it could be shared across clients using the enterprise bean instance's handle). In essence, a stateful session bean is a logical extension of the client, except that some of the client's load is distributed between itself and the enterprise bean on the server. Any conversational state-related data in the object's variables doesn't survive a server shutdown or crash, although a vendor could provide an enhanced implementation to make shutdowns and crashes transparent to the client by maintaining the enterprise bean's state.