And in reference to the class SecondaryStatelessBean, this is an example of how a Stateless class should NOT be used.
From JavaEnterPrise Beans:
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.
Bypassing conversational state doesn’t mean that a stateless session bean can’t have instance variables or maintain any kind of internal state. Nothing prevents you from keeping a variable that tracks the number of times a bean instance has been called or
a variable that saves data for debugging. However, it is important to remember that this state may never be visible to a client. The caller of an SLSB can’t assume that the same bean instance will service all of its requests. Instance variables may have different values in different bean instances, so their state is likely to appear to change randomly as stateless session beans are swapped from one client to another. Therefore, anything you reference in instance variables should be generic and not leaked out through the API.
As a summary: SLSB are reusable. The container guarantees concurrency having a pool of instances, so NEVER two users will consume the same instance at the same time. The container choose one instance among all the available instances on the pool.
For this reason, in the example, the value retrieved in primaryStatelessBean.getMessage() is the one set in the previous call. If you perform the test with ab (Apache Benchmark) with concurrency, you would see that different instances are created and that different values would be shown.