Can a Stateless Session Bean maintain state across multiple requests? I read about a "View Iterator" pattern in an EJB book ("Performance Tuning for EJBs" ?). The web tier needs to display a portion of a music catalog to the end-user. A Stateless Session Bean retrieves entire catalog from a database and persists it in its state. Stateful session beans maintain the client's current index of the catalog, retrieves a collection of value objects from the Stateless bean, and passes the VO collection back to the client. The example implies that Stateless session beans maintain their state across multiple requests (although the state is shared by all requests). I have read elsewhere that Stateless session beans do NOT maintain state across requests. From Sun's J2EE tutorial: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts3.html
A stateless session bean does not maintain a conversational state for a particular client. When a client invokes the method of a stateless bean, the bean's instance variables may contain a state, but only for the duration of the invocation. When the method is finished, the state is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client.
Which would be a correct statement: A: Stateless session beans can maintain state across multiple requests, although it should only be in read-only situations. B: Stateless session beans do NOT maintain state between requests. The EJB container resets the bean's state between invocations. C: Keep reading, you're way off. Thanks!
A: Stateless session beans can maintain state across multiple requests, although it should only be in read-only situations. B: Stateless session beans do NOT maintain state between requests. The EJB container resets the bean's state between invocations.
I would say A is more correct. It's possible to maintain read-only state in an SLSB but that's not really state then, is it?
It's possible to maintain read-only state in an SLSB but that's not really state then, is it?
That's true I suppose. Assume that the instance variables are written to by the clients. Does the bean hold that state as long as the bean exists? I can't imagine when this would be desired behavior. I'm curious if the container re-initializes a stateless session bean between requests. If answer 'A' from above is correct, then I would assume that the container does NOT re-init the bean.
Originally posted by Roger Graff: I'm curious if the container re-initializes a stateless session bean between requests. If answer 'A' from above is correct, then I would assume that the container does NOT re-init the bean.
It is up to the Container. The Spec allows the creation of a new instance for each call to create(). However, every Container in existance pools Stateless Session Bean instances. Regardless, there is no guarantee that you will get the same bean instance from request to request.
A Stateless Session Bean does not maintain state. This is how the example you described works: - When Client requests multiple Records( example: Books) multiple instances of the Record class are instantiated and "cashed" by the Container. - The client then has references to the instances via the PrimaryKey. - When user requests different instances using the Key, the container either has it in memory(as an instance that was previously retrieved) or fetches it again(using the key). - This gives the effect of "maintaing state", but the container does not maintain state. Rather it has a pool of objects that it uses for multiple requests. - I like to imagine it as a box-full of slots with ID's of different items. The container either has it or fetches it. Let me know if this helped, or if you need more details(email@example.com). - Yogi.
Joined: Jan 23, 2002
Yogi, we're talking about stateless session beans that don't have primary keys like entity beans... Here's my version of an example scenario: The EJB Container has a pool of foo.bar.MyStatelessBean instances (let's call them SB1, SB2 and SB3). And of course we have the client. Let's see what the client does...
Client calls ejbCreate() and gets a reference to a stateless session bean (no particular instance!)
Client calls ejbRef.setState(), the method executes in SB1.setState()
Client calls ejbRef.setState() again, this time the method executes in SB3.setState()
Client calls ejbRef.setState() once again, this time happening to execute twice in a row in SB3.setState()
Now, after a call to setState(123) the next call to getState() could very well return 456.