conversational state of session beans

Question

I\'m reading a book on Java EE 6 and I met with the following parts:

\"Stateless: The session bean contains no conversational state between methods, and any ins

Answer 1

A real world example of a conversational state would be Shopping Cart. A user can add several items to shopping cart one by one and then call checkout. All the added times would be there

Suppose the cart is stateful, i.e. it will keep the conversational state.

cart.add(item1);  // suppose cart keep tracks of item by adding it to ArrayList
cart.add(item2);

cart.checkOut();    // at this stage both item1 and item2 would be there in ArrayList.

If the cart is stateless, each call will be independent of previous ones and at checkout it can have nothing.

For your second point The distinction is necessary due to differences in behaviour of both beans. Maintaining state require resources therefore stateful beans are not as scalable as stateless beans.

Answer 2

Regarding the second part of the question, from the java EE 6 tutorial you can read the following:

When toUse Session Beans

Stateful session beans are appropriate if any of the following conditions are true.

• The bean’s state represents the interaction between the bean and a specific client.
• The bean needs to hold information about the client across method invocations.
• The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
• Behind the scenes, the bean manages the work flow of several enterprise beans.

To improve performance, you might choose a stateless session bean if it has any of these traits.

• The bean’s state has no data for a specific client.
• In a single method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to send an email that confirms an online order.
• The bean implements a web service.

Java EE 6 Tutorial

Answer 3

at the most basic, "conversational state" refers to the value of instance fields.

For stateless session beans, the container does not guarantee that subsequent method invocations will use the same EJB instance (from the pool), hence you cannot assume that the values you placed when you call a bean method, will still be there when you call the method again (or another method of the bean).

For stateful session beans, the container guarantees that subsequent calls will use the same EJB instance, hence you can keep instance field values.

For the sake of an example, say you have a bean that has an increment() and a retrieve() method. Increment increases the stored value, and retrieve gets the current stored value.

For a stateless session bean, if you call the increment() method 5 times, it is not guaranteed that when you do a retrieve(), you'll get a 5. It is up to the container which EJB it'll assign to your call. So if you are assigned a new EJB instance, then you'll get a zero. It is also possible that the container has not cleaned up your EJB instance, so it might be possible to get a 5 -- but it is not guaranteed.

For a stateful session bean, if you call the increment method 5 times, when you retrieve the value you'll get a 5. The container guarantees that the EJB that was used the first time you called will be used for all subsequent calls.