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

Question

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.

Answer 1

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