Hi John,
In a nutshell beans are going from
Does-Not-Exist state to the
Ready state, when they are able to service client requests. Entity EJBs and SLSBs are going through the
Pooled state as well. For these two type of beans, The setSessionContext is called when the bean is transitioning from
Does-Not-Exist state to the
Pooled state. The container will pool bean instances as needed and clients have no control over this process. The setSessionContext method is called for SFSB when the bean is transitioning from
Does-Not-Exist state to
Pooled statet, via creation (clients call create on home interface).
The ejbCreate on the other hand is called always for entity EJBs and SFSBs via creation. SLSBs on the other hand are created as they are added to the pool (the create call on the home interface returns only a reference, it doesn�t physically create the instance).
ejbLoad and ejbStore are called in several different circumstances and they make sense only for entity EJBs. The one that is most important to remember is related to the transactions. As per
EJB specs the entity EJBs follows a load and store cycle ensuring that the bean gets the latest data from database before the transaction starts (ejbLoad) and flushes the data to the database before the transaction ends (ejbStore). Although this very simplistic approach will always work, it will mostly defeat the purpose of scalable application since there is now way to cache the data between transactions. It also makes no specification about the concurrency strategy. Most of the containers however have special settings for overcoming this issue, but this is another story�
Regards.