Java, stateless session bean

Stateless session beans do not maintain state. So does it mean they should not have instanc开发者_JAVA百科e variables?

Thanks,

Roger

---

The term "state" in this context is a little misleading. What it's referring to is conversational state, meaning if a client makes multiple calls the session bean has no way of knowing. Imagine a sequence of calls:

• reserveSeatsOnFlight();
• chooseMealPreference();
• confirmBooking().

What you have there is conversational state, meaning the second call must be made to the same bean as the first call or it just won't make sense. That's what stateful session beans do.

Stateless session beans can have instance variables but those are essentially global. If you have a pool of stateless session beans (which you might or might not depending on what the container decides to do), those instances variables might or might not exist from one call to the next. So generally avoid instance variables. There are other mechanisms for that kind of thing.

Let me give you an example. Imagine this call in a stateless session bean:

public void bookFlight(List<Passsenger> passengers, FlightNumber flight, Date date) {
  ...
}

if you put in an instance variable to count the number of bookings and increment it on each call then subsequent calls might call different beans so will see different values. That's what I mean about it not necessarily making sense.

So going back to the first example, one way to handle this would be to pass state back to the caller:

public interface ReservationSystem {
  public int createNewBooking();
  public int reserveSeatsOnFlight(int bookingId, int seats);
  public int chooseMealPreference(int bookingId, ...)
  ...
}

See how the above no longer has conversational state? Well it does but it's now encapsulated in the bookingId that you pass around. A stateless session bean could retrieve the booking and continue from where another left off.

---

I have often seen stateless session beans use local variables as a way to maintain "global" state within the bean (in order to avoid the onerous task of passing data from one method call within the object to another).

Having said that, these are essentially global variables within your object, and lend themselves to abuse (as they have been in most of the cases that I've seen as well). I'd tend to recommend avoiding them.

There can be cases where they are useful, though... do you have a specific usecase in mind?

---

A Stateless bean can have instance variables like any other object. It just can't use them to maintain values specific to a particular client...

---

What about holding final instance variables which are initialized at SLSB startup (i.e. in the constructor). I'm thinking of a DAO attribute which is instantiated in the constructor of the SLSB, like so:

    @Stateless
    public class MyStatelessBean() {    
    private final CustomerDAO customerDAO;

        public MyStatelessBean() {
               // Initialization code goes here
               this.customerDAO = new CustomerDAO();
        }
    ...
    }

So the DAO can be used directly in the SLSB's methods, and has not to be created everytime the DAO is neeeded. Providing of course that the DAO is stateless, which is normally the case. Connections to the database would of course be provided on demand, and never stored in the SLSB itself.