Howdy -- stateless session beans CAN have state... in the OO sense. Stateless session beans can maintain instance variable state just as well as stateFUL beans, or any other Java object. The reason that they are referred to as stateLESS is because they cannot maintain "client-specic state" (often referred to as "conversational" state). And this is only a limitation because there is not way to tie a specific stateless bean instance to a specific client.
So a client could, for example, send a value to a stateless bean and the stateless bean could indeed set the value of an instance variable based on that client-sent value. And that's technically fine. But in reality, it won't mean anything, because the next time that client makes a call, the client might get a *different* bean instance... a bean instance that doesn't have that previously-sent instance variable value.
Even though we say that a stateLESS session bean cannot remember state -- that is simply not true from a technical sense. The stateless bean can hold instance variable values... but it cannot TIE those values back to a specific client. So a stateless bean CAN remember state from the client, but the bean CANNOT REMEMBER WHICH CLIENT SENT THAT STATE!
So client A sets a value in stateless bean One.
Client B sets a different value in stateless bean Two.
On the next business call, client A might get bean Two and client B might get bean One.
The ejbPassivate() and ejbActivate() methods exist ONLY for stateFUL beans, and only to give stateFUL beans at least *some* small hope of being scalable. StateLESS beans do not need activation and passivation because they are pooled in such a way that you do not need one bean per each client.
StateLESS beans: one bean per client in an *active method invocation on the bean" (and for every client with a reference to a stateLESS bean's component interface, only a very small percentage will actually BE in the middle of an active method invocation. Most of the time is spent BETWEEN invocations, in which case there can be far fewer beans than there are clients with REFERENCES to beans of that stateless type.
StateFUL beans: one bean per client, period. Regardless of whether the client is in the middle of an invocation or not, there MUST be a bean tied to that client. That's what passivation and activation are for... to allow some of the beans to be passivated (which could be serialization, although we hope it is something more efficient like a direct copy of memory, for example) while the client is sitting there and not actively in a method call on the bean. But since the bean is tied directly to the client, every single stateFUL bean must be able to maintain state (you wouldn't want the contents of someone else's shopping cart to suddenly end up as YOUR shopping cart state, and vice-versa...)
Bottom line: can stateless beans have state? Yes, absolutely, if you define "state" in the OO sense (meaning an instance variable, in this case) and they often do (could be a database connection, for example, or the value of an environment entry or a reference to an entity bean or... anything EXCEPT client-*specific* state.
Good question, though
And this is a very common misconception (that stateless beans can't maintain instance variable state) because of the name "stateLESS". So wherever you see the phrase "stateless session bean" do a mental search-and-replace and think instead "no-client-specific-state session bean"
cheers,
Kathy
