We’ll go over all this in detail in the Session Bean chapter. For now, you need to know that session beans can be marked (at deployment time) as either stateless or stateful.
A stateful bean can remember conversational state between method calls, while a stateless bean won’t remember anything about the client between method invocations.
The phrase “conversational state” really means “client-specific state”, and a typical example is a shopping cart. It wouldn’t be fun if you (the shopper) got a cart, put something in, but then when you go to put the second thing in, the first thing vanishes from the cart. Not too user-friendly. So, a good shopping cart will keep the client shopper state (i.e. the items in the cart) for as long as the shopping session is alive. (We’ll explain what we mean by alive in the Session Bean chapter.)
Stateless beans simply forget about the client once the method call completes. So, stateless beans are for services that don’t require a continued conversation between the client and the service. That doesn’t mean the client won’t keep calling methods on the stateless bean, but it does mean that the client can’t depend on the bean remembering anything about the previous method calls.
Stateless beans CAN have state! (Just not client-specific state.)
Some people think “stateless” means “no state”. 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.
[To be continued.]