how is state of instance variables of a stateless bean preserved for next invocation in EJB?

6
votes

I am reading Java EE7 documentation and here is what it says for stateless bean. I am confused with what is meant by the statement marked in bold below

A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean's instance variables may contain a state specific to that client but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained. Clients may, however, change the state of instance variables in pooled stateless beans, and this state is held over to the next invocation of the pooled stateless bean. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a stateless session bean should apply across all clients.

However from this post, instance variables in stateless session beans

A stateless session bean is an object that does not have an associated conversational state, but may have instance state. It does not allow concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. All instances of a stateless session bean should be considered identical by the client.

I feel that there is a contradiction here. The docs claim (from my understanding) that the instance variable state is preserved across next invocations while the latter post claims there is no guarantee that the state is preserved.

please explain

P.S: I did read this post: but I did not grasp the answer

instance variables in stateless session beans

EDIT form the SO post above

Stateless Session Beans (SLSB) are not tied to one client and there is no guarantee for one client to get the same instance with each method invocation (some containers may create and destroy beans with each method invocation session, this is an implementation-specific decision, but instances are typically pooled - and I don't mention clustered environments). In other words, although stateless beans may have instance variables, these fields are not specific to one client, so don't rely on them between remote calls.

1
jakarta-eeejbstate
Yes. It's trying to say you can use instance state (applicable to all clients), but not session state (applicable to one client). Any client can get any instance from the bean pool (say a client calls a method twice, that might go to two different instances). – Elliott Frisch
@ElliottFrisch: according to this post, different clients may see different instance states in stateless bean, stackoverflow.com/questions/2351220/…. But the docs claims, state is preserved till next invocation – brain storm
Different clients may be attached to different nodes in a cluster, what exactly are you wanting to understand? State is preserved during the invocation. – Elliott Frisch
If you have an instance variable, and you modify it then the modification is persistent across every future client invocation except; If you restart the application server then it will revert. If you redeploy the application then it will revert. If you want different clients to see different instance variables, they won't. – Elliott Frisch
@brainstorm I agree, the statements are confusing. I think the difference may be to do with client state and component state. Client state will not be retained between invocations whereas component state (state which is private to the bean) can be and can be modified by a client. I think the top answer on this post may shed some light for you: stackoverflow.com/questions/134791/… – JamesB

1 Answers

10
votes

  1. SLSBs are usually created in multiples and are stashed in a pool. So for an EJB UserDataService, there'll be a number of instances created and pooled

  2. When a client requests the services of UserDataService, the container is going to serve one of the pooled instances. Any one. When two clients request the services of the same EJB, there will be two separate instances served

  3. When a client is done with an SLSB, the instance that was in use is usually returned to the pool, not destroyed. What this means is that the same unique EJB objects that were created on container startup could quite conceivably live on the heap for the duration of the container's uptime. That bears repeating: The same SLSBs that were created and pooled when the container first put the EJB into service, are kept alive through the uptime of the container

  4. What (3) means is that if a client in (2) set any variables on the instance of the EJB that it acquired from the pool and that EJB is put back into the pool, the next client that acquires that very instance will be able to see the change made to the state of that EJB (Recall that there is a (sort of) fixed number of instances of the EJBs in the pool and they are cycled among various clients requesting service).

  5. There's no guarantee which specific instance of UserDataService a requesting client will get. There's no guarantee that the client in (2) will get the same instance of UserDataService on two separate requests for that EJB. This is what is meant by no conversational state. You're not guaranteed to be talking to the same instance of that EJB over multiple invocations. This doesn't mean that the EJBs are destroyed mid request, just that in the process of cycling, you cannot be sure of what instance your client will be relating with