The answer to your first question:
Stateless session bean can hold state, but doesn�t hold client-specific state because a client is not guaranteed to use the same session bean instance for different method invocations. The container has the freedom to swap stateless instances back and forth between clients. It means after each method invocation, the stateless
EJB clears itself out from the information of the past invocations, therefore, using a stateless EJB, it does not make sense to call the create method with a parameter because immediately after the call, the parameter will be cleared. Client-independent data can be cached in a stateless bean if:
The information being cached will never change, and
The application can tolerate a copy of the same cacher repeated in each stateless bean instance that the container creates
To answer your second question:
The container preserves remote references to other beans with the conversational state when the stateful session bean is passivated. However, I do not understand why your stateful session bean refers to a stateless session bean.