The stateless session bean is designed for efficiency and simplicity. Central to its design is the absence of conversational state, which is a topic worth exploring a bit further before delving into SLSB mechanics.
When we say conversational state, we refer to information exchanged and remembered within the context of a series of requests between the Client (caller) and EJB (service). We can illustrate this simply:
Mike: Hi, my name is Mike. Service: Hello, Mike. Mike: Do you know my name? Service: Yes, your name is Mike.
Here, the state variable holding the name of the client is stored for the duration of the conversation. Stateless session beans are incapable of handling this exchange correctly; each invocation upon a SLSB proxy operates independently from those both before and after (see Figure 5-1). In fact, its underlying bean instances may be swapped interchangeably between requests.
Stateless session beans are EJB’s answer to traditional transaction-processing applications, which are executed using a procedure call. The procedure runs from beginning to end, finally returning the result. Once the invocation completes, nothing about the data that was manipulated or the details of the request is available. When finished servicing a method invocation, an SLSB instance may be reused as the target for a new request. In short, stateless session beans are engineered to be lightweight and fast at the expense of conversational state. A much better ...