Conversely, the container can create new instances when it chooses, independently of methods issued by clients. The call issued on the EJB home object returns a reference to an EJB object representing the enterprise bean. Once a client has an EJB object reference, it can issue business methods on the EJB object, which the container in turn delegates to the bean itself. The container component, which is charged with managing session beans, does not have to infer whether a session bean is stateless or not. Session beans are declared to be stateless or stateful at installation time.
Session beans are stateful if they retain state information between method calls.
Stateful session beans can be passivated or written to secondary storage, at the container's discretion, by calling the method. The EJB specification does not require containers to use the Java serialization protocol when passivating beans, but they must provide equivalent functionality. When a container determines to swap an inactive session bean back into memory, it deserializes the passive bean and calls the method. Developers of stateful session beans are responsible to ensure that state data is serializable. Caution is necessary when implementing stateful session beans in a clustered application server environment, because not all servers support synchronization of clustered stateful session beans.