Section 6.9. Session Bean Types

6.9. Session Bean Types

There are two types of Session Beans:

Stateful Session Beans

Hold on to conversational state and maintain a long-running dialog with a client. A Shopping Cart is an example.

Stateless Session Beans

Do NOT hold on to conversational state, so the client must pass all data needed by the Stateless Session Bean's business methods.

There is nothing in the example that requires us to maintain state between Session Bean calls. You'll probably find that most transactions will end up being Stateless. Here are some of the differences between Stateful and Stateless Session Beans :

• Stateful Session Beans maintain internal state, which causes significant overhead. Stateless Session Beans are lightweight and do not hold onto application-specific data members.

• A Stateful Session Bean is tied to a single client, so the container creates a new instance for each client that invokes the Bean's create( ) method. A Stateless Session Bean instance is not tied to a client, so Stateless Session Beans are more scalable because they are reusableeach instance can service multiple clients concurrently.

• Stateless Session Beans are never passivated (swapped out of the container's memory and into secondary storage) because there is no need to restore internal state, but a container can passivate a Stateful Session Bean, incurring significant I/O overhead.

Due to performance reasons, Stateful Session Beans have fallen into disuse, and we recommend using Stateless Session Beans.

There is really no difference in deploying a Stateful or Stateless Session Beanyou specify the Session Bean type in the ejb-jar.xml deployment descriptor. But before concerning ourselves with deployment, let's look at how to implement a Session Bean.